Javetina u chrootu

[Drazen Kacar]

Imam neke Java daemone na Linuxu koje sam stavio pod runit[1]. Kako ja tim
javaslucima nista ne vjerujem, stavio sam ih u chroot. To radi
zadovoljavajuce, osim jedne sitnice.

Java na svom start-upu silno zeli imati /proc, valjda da bi utvrdila gdje
je na file systemu instalirana, pa da zna odakle pokupiti libraryje. I
zato moja run skripta mounta /proc u chroot te execa Javasluk, otprilike
ovako:

rm -f "$app_pidfile"
mount -t proc proc $chroot_base/$inst/proc

exec chroot --userspec="$runas" "$chroot_base/$inst" \
java -cp "$classpath" ...

E sad, Javetini taj /proc ne treba u normalnom radu, tako da bi ga se
moglo unmountati cim se Java inicijalizira i pokrene aplikacijski kod.
Imam cak i zgodan trigger za to, jer ce aplikacija zapisati svoj PID u
file.

Medjutim, ne pada mi na pamet gdje staviti umount. Mogu u run skriptu tako
da ne execam javu nego je pokrenem u backgroundu, pa pricekam da se file
pojavi, pa unmountam, pa javu vratim u foreground. Ako to bg/fg switchanje
uopce radi kad nema controlling terminala.

Al mi se ne svidja imati run skriptu koja samo ceka da joj dijete zavrsi,
pa da i ona izadje. A i implementacija exit statusa je malo zahtjevna.

Mogao bih umount staviti u subshell koji cu pokrenuti u backgroundu, a
Javu execati, ali onda taj subshell mora nekako skuziti situacije kad je
Java crashirala prije nego je zapisala PID file, pa onda izaci. Ali mi ne
pada na pamet kako to lijepo implementirati (na Linuxu, ne mora biti
portabilno). Na Solarisu se moze cekati na exit nekog procesa tako da se
/proc/<pid>/status uvali u poll(2), ali proc(5) na Linuxu ne spominje
takve mogucnosti.

Pa ako netko ima kakvu ideju.

[1] Supervisor u stilu daemontoolsa, http://smarden.org/runit/

--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| da...@fly.srk.fer.hr

[ivan444]

Pozdrav!

On 05/16/2013 01:35 PM, Drazen Kacar wrote:
> Imam neke Java daemone na Linuxu koje sam stavio pod runit[1]. Kako ja tim
> javaslucima nista ne vjerujem, stavio sam ih u chroot. To radi
> zadovoljavajuce, osim jedne sitnice.
>

Ne znam kako riješiti opisani problem (samo mi pada na pamet da ne može
naći JRE_HOME env pa se služi heuristikom da odredi odakle da čita
stvari, ali to je samo pucanj u prazno), ali evo možda zaobilazno
riješenje. Baci pogled na:
http://commons.apache.org/proper/commons-daemon/
odnosno: http://commons.apache.org/proper/commons-daemon/jsvc.html

Radi se o alatu koji java program vrti kao daemona (odmah imaš i
parametar -user).

Nisam ga trebao po linuxom (ipak je u većini slučajeva overkill budući
da se skripta lako napiše), ali me spasilo kad sam trebao jar zavrtiti
kao windows servis.


Pozdrav,
Ivan

[Drazen Kacar]

ivan444 wrote:
> Pozdrav!
>
> On 05/16/2013 01:35 PM, Drazen Kacar wrote:
> > Imam neke Java daemone na Linuxu koje sam stavio pod runit[1]. Kako ja tim
> > javaslucima nista ne vjerujem, stavio sam ih u chroot. To radi
> > zadovoljavajuce, osim jedne sitnice.
> >
>

> Ne znam kako rije�iti opisani problem (samo mi pada na pamet da ne mo�e
> na�i JRE_HOME env pa se slu�i heuristikom da odredi odakle da �ita

> stvari, ali to je samo pucanj u prazno),

Probao postaviti JAVA_HOME i JRE_HOME, ali bez promjene. I dalje pokusava
procitati /proc/self/exe prije bilo kakvih pokusaja ucitavanja libraryja,
pa pretpostavljam da se ne radi o heuristici za slucaj da nema environment
varijable.

Testa radi, napravio sam krivotvoreni symlink za /proc/self/exe, pa je
startup dogurao malo dalje, ali Javi trebaju i razne druge stvari iz
/proc-a.

Bio ti je dobar pokusaj. :-)

> ali evo mo�da zaobilazno rije�enje. Baci pogled na:

> http://commons.apache.org/proper/commons-daemon/
> odnosno: http://commons.apache.org/proper/commons-daemon/jsvc.html
>

> Radi se o alatu koji java program vrti kao daemona (odmah imaďż˝ i
> parametar -user).

Ne vidim bas sto s tim dobijam za ovaj slucaj. Meni je chroot glavni
feature, a ne vidim da jsvc tu nesto pomaze.

[Melzzzzz]

Pogledaj kako to radi atop, chini mi se da ukljuchuje kernel accounting,
koji evidentira kad proces izadje, a to atop util-u bash treba.

[Aleksandar Ivanisevic]

Drazen Kacar <da...@fly.srk.fer.hr> writes:

> Imam neke Java daemone na Linuxu koje sam stavio pod runit[1]. Kako ja tim
> javaslucima nista ne vjerujem, stavio sam ih u chroot. To radi
> zadovoljavajuce, osim jedne sitnice.

Brijem da se tvoj glavni problem sastoji u tome da trosis zastarjeli
(sa stanovista jvm developera, a bogami opcenito) koncept izolacije
aplikacije. Nisam vidio chroot nigdje vec deceniju, osim kod
prahistorijskih stvari tipa bind ili ftpd, da bi uspjesno usao u 21
stoljece moras trosit SELinux, LXC, openvz, kvm, xen, ovooono.

> Mogao bih umount staviti u subshell koji cu pokrenuti u backgroundu, a
> Javu execati, ali onda taj subshell mora nekako skuziti situacije kad je
> Java crashirala prije nego je zapisala PID file, pa onda izaci. Ali mi ne
> pada na pamet kako to lijepo implementirati (na Linuxu, ne mora biti
> portabilno). Na Solarisu se moze cekati na exit nekog procesa tako da se
> /proc/<pid>/status uvali u poll(2), ali proc(5) na Linuxu ne spominje
> takve mogucnosti.

A sto fali tome da /proc ostane gdje je i bio? Mozes ga odmontirati i
potpuno eksterno, ziher imas neki monitoring koji se vrti svako malo
po masini, pa tamo nastrikaj da razmontira /proc kad je vec vidio da
je javasluk ok.

--
Ti si arogantan, prepotentan i peglaš vlastitu frustraciju. -- Ivan
Tišljar, hr.comp.os.linux

[Drazen Kacar]

Aleksandar Ivanisevic wrote:
> Drazen Kacar <da...@fly.srk.fer.hr> writes:
>
> > Imam neke Java daemone na Linuxu koje sam stavio pod runit[1]. Kako ja tim
> > javaslucima nista ne vjerujem, stavio sam ih u chroot. To radi
> > zadovoljavajuce, osim jedne sitnice.
>
> Brijem da se tvoj glavni problem sastoji u tome da trosis zastarjeli
> (sa stanovista jvm developera, a bogami opcenito) koncept izolacije
> aplikacije. Nisam vidio chroot nigdje vec deceniju, osim kod
> prahistorijskih stvari tipa bind ili ftpd, da bi uspjesno usao u 21
> stoljece moras trosit SELinux, LXC, openvz, kvm, xen, ovooono.

Totalno zastarjeli, ali sto ces, to mi je skoro pa poznata tehnologija.
Imam VMWareto, doduse, umjesto tih tvojih jeftinih virtualizacija. Nikad
posteni enterprajz shop kod tebe. :-P

A sto je LXC, BTW?

> A sto fali tome da /proc ostane gdje je i bio?

A ti vjerujes svemu onome sto se skriva tamo?

> Mozes ga odmontirati i potpuno eksterno, ziher imas neki monitoring
> koji se vrti svako malo po masini, pa tamo nastrikaj da razmontira
> /proc kad je vec vidio da je javasluk ok.

Monitoring nema write & execute permissione jer ja tome nista ne vjerujem.
Ali da, mogu s necim takvim, osim sto mi to nije dovoljno picajzlasto. :-)

[Jakov Sosic]

On Fri, 17 May 2013 15:29:31 +0000, Drazen Kacar wrote:

> A sto je LXC, BTW?

Pokusaj reimplementacije kotaca (jos jedan zone-alike virtualization,
iako linux vec ima openvz).




--
HDZ vs SDP is like Alien vs. Predator. Whoever wins, we lose.

[Drazen Kacar]

Jakov Sosic wrote:
> On Fri, 17 May 2013 15:29:31 +0000, Drazen Kacar wrote:
>
> > A sto je LXC, BTW?
>
> Pokusaj reimplementacije kotaca (jos jedan zone-alike virtualization,
> iako linux vec ima openvz).

Hm, ne djeluje mi �ivahno s obzirom da je zadnji release iz 2011-e.

http://lxc.sourceforge.net/index.php/news/

Openvz djeluje �ivlje, ali mi nije ba� jasno koliko je to stabilno.

[Jakov Sosic]

On Fri, 17 May 2013 18:35:13 +0000, Drazen Kacar wrote:

> Jakov Sosic wrote:
>> On Fri, 17 May 2013 15:29:31 +0000, Drazen Kacar wrote:
>>
>> > A sto je LXC, BTW?
>>
>> Pokusaj reimplementacije kotaca (jos jedan zone-alike virtualization,
>> iako linux vec ima openvz).
>

> Hm, ne djeluje mi živahno s obzirom da je zadnji release iz 2011-e.
>
> http://lxc.sourceforge.net/index.php/news/
>
> Openvz djeluje življe, ali mi nije baš jasno koliko je to stabilno.

Vrtili smo ga neko vrijeme i radio je skroz ok (CentOS 5.x). Ne znam
kakva je situacija danas.

[Josip Almasi]

Drazen Kacar wrote:
>
> Openvz djeluje �ivlje, ali mi nije ba� jasno koliko je to stabilno.

Ovolko:
https://bugzilla.openvz.org/buglist.cgi?product=OpenVZ&component=kernel&resolution=---

Pozdrav...

[Matija Nalis]

On Thu, 16 May 2013 11:35:22 +0000 (UTC), Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> E sad, Javetini taj /proc ne treba u normalnom radu, tako da bi ga se
> moglo unmountati cim se Java inicijalizira i pokrene aplikacijski kod.
> Imam cak i zgodan trigger za to, jer ce aplikacija zapisati svoj PID u
> file.
>
> Medjutim, ne pada mi na pamet gdje staviti umount. Mogu u run skriptu tako
> da ne execam javu nego je pokrenem u backgroundu, pa pricekam da se file
> pojavi, pa unmountam, pa javu vratim u foreground. Ako to bg/fg switchanje
> uopce radi kad nema controlling terminala.

^z, bg/fg ne radi, ali jobovi normalno rade...
Run scripta bi ti onda bila nesto tipa:

#!/bin/sh

rm -f "$app_pidfile"
mount -t proc proc $chroot_base/$inst/proc

chroot ... java -cp "$classpath" ... &
while [ ! -f /var/run/nesto_tvoje.pid ] ; do sleep 2; done
umount $chroot_base/$inst/proc
wait


mozes umjesto while reda koristiti iwatch(1) ili nesto drugo fancy da bude
optimiziranje, ali tu nije bas jako bitno... "wait" na kraju je bitan da ti
scripta ostane cekati dok svi background jobovi ne poumiru (inace ce ti
supervise/runit postati fork-bomb :)

> Al mi se ne svidja imati run skriptu koja samo ceka da joj dijete zavrsi,
> pa da i ona izadje. A i implementacija exit statusa je malo zahtjevna.

Po meni ce ti puno ljepse (i u duhu run scripte) izgledati u "ps auxf" (ah,
"ps -efH"?) tamo gore.

I traceabilnije ako slucajno ostane visiti nesto, stale .pid fileovi ili
sl). No ako te brinu resursi koje zauzima idle /bin/sh ili taj red u ps(1)
ili nesto, vidi nize, ali puno gnjavaze za mikro koristi...

> Mogao bih umount staviti u subshell koji cu pokrenuti u backgroundu, a
> Javu execati, ali onda taj subshell mora nekako skuziti situacije kad je
> Java crashirala prije nego je zapisala PID file, pa onda izaci. Ali mi ne
> pada na pamet kako to lijepo implementirati (na Linuxu, ne mora biti
> portabilno). Na Solarisu se moze cekati na exit nekog procesa tako da se
> /proc/<pid>/status uvali u poll(2), ali proc(5) na Linuxu ne spominje
> takve mogucnosti.

pa "portabilno" na oba ce ti biti:
while [ -f /proc/<pid>/status ] ; do sleep 2; done;

ako to zelis, onda onu while petlju

1) stavis da taj subshell sa while ide u "&"
2) prosiris navedeni while da osim na nesto_tvoje.pid pazi i na /proc/$$/status
($$ je isti sa run scriptu i za javusu kasnije, jel')
3) javu ostavis na kraju sa exec

jedino ti preostaje smisliti logiku za (2) koliko zelis da bude kompleksna.
tu imas par varijanti (ovisno o kompleksnosti zeljeti ces to izvuci u
posebnu scriptu, a ne kao glomazni inline subshell koji ces copy/pasteati
onda u desetine run scripti za desetine javustina):

a) obicni timeout. neka gleda samo "nesto_tvoje.pid", a ako u 50 puta po 2
sekunde ne uspije, neka napravi nesto (ipak odmounta proc, ili kill -9
javesinu pa onda odmounta ili samo ubije sebe a ostavi javusinu sa procom
ili stogod vec)

b) timeout kao i u (a), ali da gleda i da li postoji /proc/$$/status kako bi
vidio sto je problem (javusina koja je umrla prije kreiranja pid, ili
koja nije kreirala pid iako je trebala a jos se vrti ili nesto trece).
Tu imas dodatni issue sto je teoretski moguce (iako malo vjerojatno) da
je javusina umrla, ali se startao novi proces (mozda cak opet neka druga
javusina?) sa istim PIDom. Pa onda moras ili prihvatiti da ces nekad
donjeti krivu odluku, ili se upustiti u parent-pid analizu i uvjeriti se
da i ti i ta javetina imate istog parenta...

detalje implementacije ostavljamo za vjezbu OPu (ili potencijalnom GNU
konzultantu kojeg ce isti odluciti platiti za state-of-the-art rjesenje :)

> Pa ako netko ima kakvu ideju.

Stavi grsec patch na kernel, i lijepo umjesto chroota definiraj sto taj java
proces smije vidjeti od filesystem (i drugih) namespaceova (brijem da FS dio
mozes i sa ugradjenim SElinux, ali ne volem ga). Dodatni bonus je sto
javusini mozes ograniciti i mrezne mogucnosti i capabilities i ne dati joj
da vidi CIJELI /proc nego samo ono sto treba od tamo i jos svasta nesto.

--
Opinions above are GNU-copylefted.

[Drazen Kacar]

Matija Nalis wrote:
> On Thu, 16 May 2013 11:35:22 +0000 (UTC), Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> > E sad, Javetini taj /proc ne treba u normalnom radu, tako da bi ga se
> > moglo unmountati cim se Java inicijalizira i pokrene aplikacijski kod.
> > Imam cak i zgodan trigger za to, jer ce aplikacija zapisati svoj PID u
> > file.
> >
> > Medjutim, ne pada mi na pamet gdje staviti umount. Mogu u run skriptu tako
> > da ne execam javu nego je pokrenem u backgroundu, pa pricekam da se file
> > pojavi, pa unmountam, pa javu vratim u foreground. Ako to bg/fg switchanje
> > uopce radi kad nema controlling terminala.
>
> ^z, bg/fg ne radi, ali jobovi normalno rade...
> Run scripta bi ti onda bila nesto tipa:
>
> #!/bin/sh
> rm -f "$app_pidfile"
> mount -t proc proc $chroot_base/$inst/proc
> chroot ... java -cp "$classpath" ... &
> while [ ! -f /var/run/nesto_tvoje.pid ] ; do sleep 2; done
> umount $chroot_base/$inst/proc
> wait
>
>
> mozes umjesto while reda koristiti iwatch(1) ili nesto drugo fancy da bude
> optimiziranje, ali tu nije bas jako bitno... "wait" na kraju je bitan da ti
> scripta ostane cekati dok svi background jobovi ne poumiru (inace ce ti
> supervise/runit postati fork-bomb :)

Aha. :-)

I jos bi trebalo exit status djeteta vratiti iz te skripte, ukljucujuci i
informaciju da je terminirano nekim signalom (kad se to dogodi). Nisam
nikad iz shell skripte pokusavao vratiti signal exit status. A ni iz C
programa, kad bolje razmislim.

> > Al mi se ne svidja imati run skriptu koja samo ceka da joj dijete zavrsi,
> > pa da i ona izadje. A i implementacija exit statusa je malo zahtjevna.
>
> Po meni ce ti puno ljepse (i u duhu run scripte) izgledati u "ps auxf" (ah,
> "ps -efH"?) tamo gore.

Eh? Nisam shvatio.

> I traceabilnije ako slucajno ostane visiti nesto, stale .pid fileovi ili
> sl). No ako te brinu resursi koje zauzima idle /bin/sh ili taj red u ps(1)
> ili nesto, vidi nize, ali puno gnjavaze za mikro koristi...

Ne brine me zbog zauzimanja resursa, samo mi ide na zivce. A i zanima me.
Sto ne znaci da bih nuzno htio i implementirati svaku mikro optimizaciju.

> > Mogao bih umount staviti u subshell koji cu pokrenuti u backgroundu, a
> > Javu execati, ali onda taj subshell mora nekako skuziti situacije kad je
> > Java crashirala prije nego je zapisala PID file, pa onda izaci. Ali mi ne
> > pada na pamet kako to lijepo implementirati (na Linuxu, ne mora biti
> > portabilno). Na Solarisu se moze cekati na exit nekog procesa tako da se
> > /proc/<pid>/status uvali u poll(2), ali proc(5) na Linuxu ne spominje
> > takve mogucnosti.
>
> pa "portabilno" na oba ce ti biti:
> while [ -f /proc/<pid>/status ] ; do sleep 2; done;

Tko mi garantira da u te dvije sekunde PID nece pripasti nekom
novostvorenom procesu?

> ako to zelis, onda onu while petlju

Ne bas, kad god implementiram nekakvo pollanje osjecam se izuzetno
nekompetentno. Ja bih nesto sto spava dok ga odgovarajuci event ne
probudi (moze imati i poneki spurious wakeup, ako bas mora). Inace mi bez
veze trosi struju.

> detalje implementacije ostavljamo za vjezbu OPu (ili potencijalnom GNU
> konzultantu kojeg ce isti odluciti platiti za state-of-the-art rjesenje :)

State-of-the-art od prije 20 godina je nesto blokirajuce sto nece
zahtijevati ekstra proces do kraja izvrsavanja Javetine. :-)

> > Pa ako netko ima kakvu ideju.
>
> Stavi grsec patch na kernel, i lijepo umjesto chroota definiraj sto taj
> java proces smije vidjeti od filesystem (i drugih) namespaceova (brijem
> da FS dio mozes i sa ugradjenim SElinux, ali ne volem ga). Dodatni
> bonus je sto javusini mozes ograniciti i mrezne mogucnosti i
> capabilities i ne dati joj da vidi CIJELI /proc nego samo ono sto treba
> od tamo i jos svasta nesto.

Namjeravao sam mrezu ograniciti pomocu SElinuxa (kad je vec tamo), ali
ne osjecam se bas najbolje s tim skalamerijama. Implementacija chroota u
kernelu je izuzetno jednostavna i vrlo je mala mogucnost da ce imati
ikakvih bugova.

S druge strane, implementacija label securityja je kompleksno cudoviste za
koje bih ja, ovako laicki, ocekivao da ima pristojnu kolicinu bugova. Od
kojih ce onda neki biti i security bugovi. Sto nas dovodi do potencijalno
perverzne situacije: upogonis label security da bi povecao sigurnost svog
sustava, a onda ti hax0ri sve isprovaljuju zbog rupa u toj sigurnosnoj
skalameriji.

Ali, kako rekoh, to je samo moj laicki i potencijalno paranoicni pogled na
stvari.

[Drazen Kacar]

Drazen Kacar wrote:

> State-of-the-art od prije 20 godina je nesto blokirajuce sto nece
> zahtijevati ekstra proces do kraja izvrsavanja Javetine. :-)

Zaboravih spomenuti: upotrebljavanje API-ja za debuggere (ptrace(2) na
Linuxu) se ne racuna u state of the art. Racuna se u perverziju.

[Aleksandar Ivanisevic]

Drazen Kacar <da...@fly.srk.fer.hr> writes:

>
> A sto je LXC, BTW?

To je rewrite openvza jer je diktator Linus rekao da je openvz
preveliki patch da ikada udje u kernel pa su jadni ljudi koji zele
light containere, a ne zele custom kernel morali razvijat to
ispocetka.

>> A sto fali tome da /proc ostane gdje je i bio?
>
> A ti vjerujes svemu onome sto se skriva tamo?

Ovisi o procjeni. Mislim jasno je meni da me prate, ali u jednom
trenutku treba sjest i procijenit koja je realna vjerojatnost da ce mi
netko provalit.

>> Mozes ga odmontirati i potpuno eksterno, ziher imas neki monitoring
>> koji se vrti svako malo po masini, pa tamo nastrikaj da razmontira
>> /proc kad je vec vidio da je javasluk ok.
>
> Monitoring nema write & execute permissione jer ja tome nista ne vjerujem.
> Ali da, mogu s necim takvim, osim sto mi to nije dovoljno
> picajzlasto. :-)

A sto recimo fali SELinuxu, pa to je bas prava stvar za paranoicne sa
ogromnim viskom vremena?

[Aleksandar Ivanisevic]

Drazen Kacar <da...@fly.srk.fer.hr> writes:

> Jakov Sosic wrote:
>> On Fri, 17 May 2013 15:29:31 +0000, Drazen Kacar wrote:
>>
>> > A sto je LXC, BTW?
>>
>> Pokusaj reimplementacije kotaca (jos jedan zone-alike virtualization,
>> iako linux vec ima openvz).
>

> Hm, ne djeluje mi živahno s obzirom da je zadnji release iz 2011-e.

Brijem da otkad ih je Adolf Torvalds primio u clanstvo ne razvijaju
poseban patch nego dobijes to s kernelom.

[...]

[Aleksandar Ivanisevic]

Josip Almasi <j...@vrspace.org> writes:

> Drazen Kacar wrote:
>>

>> Openvz djeluje življe, ali mi nije baš jasno koliko je to stabilno.
>
> Ovolko:
> https://bugzilla.openvz.org/buglist.cgi?product=OpenVZ&component=kernel&resolution=---

Openvz je stijena stamena, ja u njemu vrtim 100 virtualki vec 5 godina
i nikad nista iako ga silim i sa drbdom i kvmom u isto vrijeme. Cak
ponegdje vrtim i rhel6 kernel na rhel5 bazi cisto zato jer mi je vec
dosadno kako se nis ne dogadja, ali avaj ;)

[Drazen Kacar]

Aleksandar Ivanisevic wrote:
> Drazen Kacar <da...@fly.srk.fer.hr> writes:

> >> A sto fali tome da /proc ostane gdje je i bio?
> >
> > A ti vjerujes svemu onome sto se skriva tamo?
>
> Ovisi o procjeni. Mislim jasno je meni da me prate, ali u jednom
> trenutku treba sjest i procijenit koja je realna vjerojatnost da ce mi
> netko provalit.

A kako se to procjenjuje?

> > Monitoring nema write & execute permissione jer ja tome nista ne vjerujem.
> > Ali da, mogu s necim takvim, osim sto mi to nije dovoljno
> > picajzlasto. :-)
>
> A sto recimo fali SELinuxu, pa to je bas prava stvar za paranoicne sa
> ogromnim viskom vremena?

Nekako ne vidim ogromni visak vremena kod sebe. Cak ni mali visak. :-(

[Aleksandar Ivanisevic]

Drazen Kacar <da...@fly.srk.fer.hr> writes:

> Aleksandar Ivanisevic wrote:
>> Drazen Kacar <da...@fly.srk.fer.hr> writes:
>
>> >> A sto fali tome da /proc ostane gdje je i bio?
>> >
>> > A ti vjerujes svemu onome sto se skriva tamo?
>>
>> Ovisi o procjeni. Mislim jasno je meni da me prate, ali u jednom
>> trenutku treba sjest i procijenit koja je realna vjerojatnost da ce mi
>> netko provalit.
>
> A kako se to procjenjuje?

To je zapravo cijela nauka, a bogami i requirement ako hoces da ti
firma dobije prakticki bilo koji od ovih raznih iso-miso certifikata.

Prakticki se svede na to da svi oni koji znaju o cemu se radi sjednu
za stol i razmatraju razne scenarije koji bi se mogli dogoditi te
kolika je vjerojatnost istih u omjeru prema trudu koji treba uloziti
da bi se rizik smanjio.

Dakle u tom tvom slucaju zapitas se da li je fakat vrijedno izgubit 10
dana tjerajuci javu da radi u chrootu sa razmontiranim procom kad je
sve sto vrti interni servis iza sedam firewalla koji kad provalis
saznas datum rodjenja direktorovog papagaja.

>> > Monitoring nema write & execute permissione jer ja tome nista ne vjerujem.
>> > Ali da, mogu s necim takvim, osim sto mi to nije dovoljno
>> > picajzlasto. :-)
>>
>> A sto recimo fali SELinuxu, pa to je bas prava stvar za paranoicne sa
>> ogromnim viskom vremena?
>
> Nekako ne vidim ogromni visak vremena kod sebe. Cak ni mali
> visak. :-(

A ipak imas dovoljno vremena jebat se sa chrootovima. Zanimljivo. Meni
se cini da je selinux puno laksi za setapirat, pustis ga u logging
modu i zavrces pipu malo po malo dok log ne prestane ili je sve sto je
ostalo bezopasno/nepotrebno i onda zavrnes do kraja. Nesto slicno ko
kad meces firewall ispred radece aplikacije, traje dugo ako hoces biti
100% ziher, ali zapravo nema previse posla.

[Walter Gottwein]

On 2013-05-21, Aleksandar Ivanisevic <aleks...@ivanisevic.de> wrote:
> A sto recimo fali SELinuxu, pa to je bas prava stvar za paranoicne sa
> ogromnim viskom vremena?

Neke servise zna znacajno usporiti npr. probaj ga pokrenuti u
Apache + mod_auth_kerb konfiguraciji.

--
Pozdrav,
Walter

[Josip Almasi]

Aleksandar Ivanisevic wrote:
> Josip Almasi<j...@vrspace.org> writes:
>
>> Drazen Kacar wrote:
>>>
>>> Openvz djeluje življe, ali mi nije baš jasno koliko je to stabilno.
>>
>> Ovolko:
>> https://bugzilla.openvz.org/buglist.cgi?product=OpenVZ&component=kernel&resolution=---
>
> Openvz je stijena stamena, ja u njemu vrtim 100 virtualki vec 5 godina
> i nikad nista iako ga silim i sa drbdom i kvmom u isto vrijeme.

Blago tebi.
A jao onima kojima tvoja rijec vrijedi vise od bugliste.

Pozdrav...

[Drazen Kacar]

Aleksandar Ivanisevic wrote:
> Drazen Kacar <da...@fly.srk.fer.hr> writes:

> > A kako se to procjenjuje?

>
> Prakticki se svede na to da svi oni koji znaju o cemu se radi sjednu
> za stol i razmatraju razne scenarije koji bi se mogli dogoditi te
> kolika je vjerojatnost istih u omjeru prema trudu koji treba uloziti
> da bi se rizik smanjio.

Toliko znam, ali mi nije jasno kako se procjenjuje vjerojatnost provale po
nekom scenariju. Nisam nikad provaljivao nigdje, pa mi je znanje o toj
strani negdje na nuli. Ostalima "koji znaju o cemu se radi" isto. Trud
koji treba uloziti da bi se rizik smanjio mogu procijeniti.

> Dakle u tom tvom slucaju zapitas se da li je fakat vrijedno izgubit 10
> dana tjerajuci javu da radi u chrootu sa razmontiranim procom kad je
> sve sto vrti interni servis iza sedam firewalla koji kad provalis
> saznas datum rodjenja direktorovog papagaja.

Da je interni servis u pitanju nikad to chroota ne bi vidjelo. A i nije
neki problem natjerati Javu da radi u chrootu. To sto cu ovdje eventualno
10 dana raspravljati o tome sto bi se i kako bi se moglo napraviti ne
znaci da cu to sve i krenuti raditi.

> > Nekako ne vidim ogromni visak vremena kod sebe. Cak ni mali
> > visak. :-(
>
> A ipak imas dovoljno vremena jebat se sa chrootovima. Zanimljivo. Meni
> se cini da je selinux puno laksi za setapirat,

Nemam pojma, nisam nikad pokusao nista raditi sa selinuxom.

> pustis ga u logging modu i zavrces pipu malo po malo dok log ne
> prestane ili je sve sto je ostalo bezopasno/nepotrebno i onda zavrnes
> do kraja. Nesto slicno ko kad meces firewall ispred radece aplikacije,
> traje dugo ako hoces biti 100% ziher, ali zapravo nema previse posla.

Aha.

[Aleksandar Ivanisevic]

Drazen Kacar <da...@fly.srk.fer.hr> writes:

> Toliko znam, ali mi nije jasno kako se procjenjuje vjerojatnost provale po
> nekom scenariju. Nisam nikad provaljivao nigdje, pa mi je znanje o toj
> strani negdje na nuli. Ostalima "koji znaju o cemu se radi" isto. Trud
> koji treba uloziti da bi se rizik smanjio mogu procijeniti.

Pa ako nesto neznas, onda platis konzultanta koji ce ti to objasnit,
pa to je bar jednostavno ;)

Cak i ako ne znas procijeniti koliki je apsolutni rizik, a ne zelis
platit nekoga da to ucini za tebe, mozes procijeniti koliki je
relativni prema ostatku skalamerije pa se prema tome dalje ravnati.

[...]

>
> Nemam pojma, nisam nikad pokusao nista raditi sa selinuxom.
>

Niti sam ja ikad ista metao u chroot, tak da je situacija standardna:
palamudimo bezveze ;)

[...]

[Matija Nalis]

Zasto? To je sad dodatni requirement (zelis logirati razlog umiranja itd)
ili mislis radi ovog gore (kojem je nebitno je li javusa umrla ili se
pidfile pojavio, a kamo li zasto je javusa umrla).

Jer ako je to da zelis logirati, onda ce ti definitivno *morati* visiti
stalno neka scripta (jer tko ce zalogirati? ako ne mislis patchirati javu
ili bolje kernel[1]), pa ti je ta originalna "run" scripta bolje rjesenje
od neke druge nevezane run scripte. Ili ne vidim sto te muci?

Jer po meni tvoje originalno pitanje ima smisla jedino radi ljepote ps(1)
ispisa, a to moze samo ako scripta radi *samo* umount te moze umrijeti odmah
nakon istog (jer ce ispis tada biti ruzan samo par sekundi, koliko vec javi
treba da kreira pidfile)

> informaciju da je terminirano nekim signalom (kad se to dogodi). Nisam
> nikad iz shell skripte pokusavao vratiti signal exit status. A ni iz C
> programa, kad bolje razmislim.
>
>> > Al mi se ne svidja imati run skriptu koja samo ceka da joj dijete zavrsi,
>> > pa da i ona izadje. A i implementacija exit statusa je malo zahtjevna.
>>
>> Po meni ce ti puno ljepse (i u duhu run scripte) izgledati u "ps auxf" (ah,
>> "ps -efH"?) tamo gore.
>
> Eh? Nisam shvatio.

"ps auxf" ce ti nacrtati nesto tipa:

root 1984 0.0 0.0 21876 380 ? S May13 0:00 | \_ supervise zla_java
root 9543 0.0 0.0 15396 516 ? S May20 0:00 | | \_ /bin/sh ./run
root 9573 0.0 0.0 14304 4340 ? S May20 0:06 | | \_ java blabhblahblah


ako napravis exec, pa onda imas posebnu scriptu koja sa strane ceka da umounta, ce to izgledati:

root 1984 0.0 0.0 21876 380 ? S May13 0:00 | \_ supervise zla_java
root 9543 0.0 0.0 15396 516 ? S May20 0:00 | | \_ java blahblahblah
root 9573 0.0 0.0 14304 4340 ? S May20 0:00 | | \_ /bin/sh cekaj_i_radi_umount_itd

ono gore je ljepse i citljivije od ovog dolje, to sam htio reci... (a i ima
manje potencijalnih problema kada zelis stopati proces sa runit ekvivalentom
"svc -d")

>> I traceabilnije ako slucajno ostane visiti nesto, stale .pid fileovi ili
>> sl). No ako te brinu resursi koje zauzima idle /bin/sh ili taj red u ps(1)
>> ili nesto, vidi nize, ali puno gnjavaze za mikro koristi...
>
> Ne brine me zbog zauzimanja resursa, samo mi ide na zivce. A i zanima me.
> Sto ne znaci da bih nuzno htio i implementirati svaku mikro optimizaciju.
>
>> > Mogao bih umount staviti u subshell koji cu pokrenuti u backgroundu, a
>> > Javu execati, ali onda taj subshell mora nekako skuziti situacije kad je
>> > Java crashirala prije nego je zapisala PID file, pa onda izaci. Ali mi ne
>> > pada na pamet kako to lijepo implementirati (na Linuxu, ne mora biti
>> > portabilno). Na Solarisu se moze cekati na exit nekog procesa tako da se
>> > /proc/<pid>/status uvali u poll(2), ali proc(5) na Linuxu ne spominje
>> > takve mogucnosti.
>>
>> pa "portabilno" na oba ce ti biti:
>> while [ -f /proc/<pid>/status ] ; do sleep 2; done;
>
> Tko mi garantira da u te dvije sekunde PID nece pripasti nekom
> novostvorenom procesu?

na defaultnom Linuxu, tvoj hardver :) jer PID raste inkrementalno do
/proc/sys/kernel/pid_max, pa wraparounda tek onda. Vidi kernel/pid.c

>> ako to zelis, onda onu while petlju
>
> Ne bas, kad god implementiram nekakvo pollanje osjecam se izuzetno
> nekompetentno. Ja bih nesto sto spava dok ga odgovarajuci event ne
> probudi (moze imati i poneki spurious wakeup, ako bas mora). Inace mi bez
> veze trosi struju.

Pa to radi wait(2) :-) Ali ti onda ima proces viska i cini ti se "ruzno".
Ili spomenuti iwatch(1), ali ti ne bi "niti htio implementirati svaku mikro
optimizaciju". Pollanje resursa svake 2 sekunde je dosta zanemarivo, znas?
Pogotovo ako vec vrtis *javuse* na masini..

Mislim da je ono sto ti zapravo zelis monit(1) a ne runit(1).
ili nesto jos radikalnije - vidi nize...

>> detalje implementacije ostavljamo za vjezbu OPu (ili potencijalnom GNU
>> konzultantu kojeg ce isti odluciti platiti za state-of-the-art rjesenje :)
>
> State-of-the-art od prije 20 godina je nesto blokirajuce sto nece
> zahtijevati ekstra proces do kraja izvrsavanja Javetine. :-)

state of the art ti je nekompatibilan sa runit tehnologijom, koja se bazira
na toj "run" scripti koju ti zelis eliminirati. Dosta je jednostavno
napraviti rjesenje gdje neces imati taj extra run proces (i neces niti imati
extra "supervise" i logger procesa, dapace).

runit/daemontools nisi radjeni za smanjenje broja procesa, nego za izolaciju
svakog posebno (a bas naustrb broja procesa).

Nisam bas puno probavao, ali pogledaj rjesnja novija od sysvinit i
deaemontoolsa za managanje deamona, tipa upstart ili systemd ili sl.

Ili napravi svoju reimplementaciju ako te bas toliko veseli, nije
bas komplicirano (ali niti kompatibilno sa runitom bas) :

- startas novi master proces (dignut na bilo koji nacin: od sysvinita, inittaba,
daemontoolsa/runita, stogod) koji ti je novi master za sve javuse i sl.:

- forka i execa sve javuse i ostalo koje imas
- forka jedan logger proces (zato da blokiranje istog npr. disk full ne
blokira i system)
- salje stdout/stderr od javusa loggeru koji to zapisuje (preko pipe(2))
- gleda da li se pojavio pidfile i forka/execa odgovarajuci umount.
(koristeci inotify, da ne bude "wasteful" pollanje stalno)
- alarm(2)a na x minuta ili koliko vec zelis, kako bi pobio javuse koje
nisu na vrijeme kreirale pidfile niti umrle
- waitpid(2)-a da vidi da li je koji od childova umro, kako bi mu
zabiljezio sto i kako u log.
- ponovi citavu stvar kako tko umre i/ili izvrsi potrebnu akciju

nema rastrosnog pollanja svakih par sekundi, ako imas 10 javusa imas samo 10
(javuse) + 2 (master i logger) = 12 stalno vrtecih procesa (i povremeno neki
kratkorocno vrteci umount(8) - je ne zelis umount(2) vrtiti u master procesu,
radi mogucih blokiranja i sl.)

Umjesto trenutnog rjesnja sa 10 (superviseovi za javuse) + 10 (run scripta
za javuse koje cekaju za umount) + 10 (same javuse) + 10 (supervisovi za
logger) + 10 (sami loggeri) + 1 (master svscanboot) = 51 stalno vrtecih (i
povremeno neki forkani umount).

Ili kada bi eliminirao te run scrpte (tvoja inicijalna zamisao), 41 stalno
vrteci proces (i opet nesto povremenih za scripte koje cekaju umount
trenutak + sami umountovi).

s/supervise/runit_ekvivalent/g;

> Ali, kako rekoh, to je samo moj laicki i potencijalno paranoicni pogled na
> stvari.

ili ako te vec vrti paranoja, vrti virtualku za svaku javusu i stavi je u
inittab(5), to ce ti biti znacajno sigurnije od chroota, a i ps(1) output ce
izgledati cisto i stati na jedan ekran :) Da ne spominjemo da ce imati
znacajno manje interakcijskih problema jer ce svaka javusa imati svoj svijet
koji ce joj izgledati tocno onakvim kakvim zamislja...


[1] spomenuti grsec ce ti uz sve ostale prednosti i zabiljeziti koji proces
je umro nenormalno (SIGILL, SIGSEGV, ...)

[Drazen Kacar]

Matija Nalis wrote:
> On Mon, 20 May 2013 07:28:22 +0000 (UTC), Drazen Kacar <da...@fly.srk.fer.hr> wrote:

> >> "wait" na kraju je bitan da ti scripta ostane cekati dok svi
> >> background jobovi ne poumiru (inace ce ti supervise/runit postati
> >> fork-bomb :)
> >
> > Aha. :-)
> >
> > I jos bi trebalo exit status djeteta vratiti iz te skripte, ukljucujuci i
>
> Zasto? To je sad dodatni requirement (zelis logirati razlog umiranja itd)

Nije dodatni. U prvom postu sam napisao "A i implementacija exit statusa
je malo zahtjevna." misle�i na to.

Ali da, �elim logirati.

> Jer ako je to da zelis logirati, onda ce ti definitivno *morati* visiti
> stalno neka scripta (jer tko ce zalogirati? ako ne mislis patchirati javu
> ili bolje kernel[1]), pa ti je ta originalna "run" scripta bolje rjesenje
> od neke druge nevezane run scripte. Ili ne vidim sto te muci?

Visi runit. :-) Da budem precizniji, visi supervisor proces (runsv), a kad
njegov servis ugine, on pokupi status i pozove skriptu finish koja onda
taj status dobije (zajedno s brojem signala, ako je zbog toga proces
izasao). Tako da u normalnim uvjetima finish skripta logira.

> Jer po meni tvoje originalno pitanje ima smisla jedino radi ljepote ps(1)
> ispisa,

Da, a i zanima me kako se te stvari mogu napraviti.

> a to moze samo ako scripta radi *samo* umount te moze umrijeti odmah
> nakon istog (jer ce ispis tada biti ruzan samo par sekundi, koliko vec
> javi treba da kreira pidfile)

Da.

> > Eh? Nisam shvatio.
>
> "ps auxf" ce ti nacrtati nesto tipa:

Aha. Nisam nikad koristio ps za takvo crtanje. Nisam ni znao da Linuxov ps
to mo�e. Obi�no koristim pstree za to.

> ono gore je ljepse i citljivije od ovog dolje, to sam htio reci... (a i ima
> manje potencijalnih problema kada zelis stopati proces sa runit ekvivalentom
> "svc -d")

�to jest - jest. Ako skripta ostane visiti, mora joj se implementirati da
dobar dio signala hvata i prenosi svom djetetu. �to me ba� ne odu�evljava.

> > Tko mi garantira da u te dvije sekunde PID nece pripasti nekom
> > novostvorenom procesu?
>
> na defaultnom Linuxu, tvoj hardver :) jer PID raste inkrementalno do
> /proc/sys/kernel/pid_max, pa wraparounda tek onda. Vidi kernel/pid.c

Ma da, ali... Tko mi garantira da se algoritam u pid.c ne�e promijeniti u
skoroj budu�nosti?

> > Ne bas, kad god implementiram nekakvo pollanje osjecam se izuzetno
> > nekompetentno. Ja bih nesto sto spava dok ga odgovarajuci event ne
> > probudi (moze imati i poneki spurious wakeup, ako bas mora). Inace mi bez
> > veze trosi struju.
>
> Pa to radi wait(2) :-) Ali ti onda ima proces viska i cini ti se "ruzno".

Nije ru�no, nego mi ide na �ivce. :-) A moram i implementirati prijenos
signala djetetu.

> Ili spomenuti iwatch(1), ali ti ne bi "niti htio implementirati svaku mikro
> optimizaciju".

Nisam rekao da ne bih htio, nego da ne�u nu�no. iwatch, odn. inotify-wait
je ok.

> Pollanje resursa svake 2 sekunde je dosta zanemarivo, znas?
> Pogotovo ako vec vrtis *javuse* na masini..

Znam. :-)

> > State-of-the-art od prije 20 godina je nesto blokirajuce sto nece
> > zahtijevati ekstra proces do kraja izvrsavanja Javetine. :-)
>
> state of the art ti je nekompatibilan sa runit tehnologijom, koja se bazira
> na toj "run" scripti koju ti zelis eliminirati.

Nije, na Solarisu bi lijepo funkcioniralo zato �to tamo mo�e� �ekati da
bilo koji proces iza�e, a ne samo tvoja djeca. Nema to veze s runit
tehnologijom.

> Nisam bas puno probavao, ali pogledaj rjesnja novija od sysvinit i
> deaemontoolsa za managanje deamona, tipa upstart ili systemd ili sl.

Mislim da neki od njih izvode ovo �to bih ja htio upotrebom ptrace(2)
poziva. Nisam ba� odu�evljen. A i nemam povjerenja u stabilnost.

> Ili napravi svoju reimplementaciju ako te bas toliko veseli, nije
> bas komplicirano (ali niti kompatibilno sa runitom bas) :

A nije ni potrebno. -)

> - forka jedan logger proces (zato da blokiranje istog npr. disk full ne
> blokira i system)
> - salje stdout/stderr od javusa loggeru koji to zapisuje (preko pipe(2))

Kad smo ve� kod toga, postoji li jedan od takvih loggera koji bi osim �to
pi�e po lokalnom disku znao te logove i pouzdano prenijeti preko mre�e?

Pouzdano okvirno zna�i da �e u slu�aju da receiver neko vrijeme ne radi
logovi biti poslani kad proradi.

> > Ali, kako rekoh, to je samo moj laicki i potencijalno paranoicni pogled na
> > stvari.
>
> ili ako te vec vrti paranoja, vrti virtualku za svaku javusu i stavi je u
> inittab(5), to ce ti biti znacajno sigurnije od chroota,

Misli�? U chrootu nema pristupa procesima koji se izvr�avaju s podignutim
privilegijama, a u virtualci ima. Nije da ja �elim maknuti proc iz chroota
da java ne bi vidjela koji se sve procesi izvr�avaju, nego o�ekujem da �e
se na�i kakav kernel bug u implementaciji koda koji �ini proc, pa �elim
maknuti mogu�nost interakcije s procom. U virtualci bi taj proc bio
dostupan.

> a i ps(1) output ce izgledati cisto i stati na jedan ekran :)

Aha. Oh, joy!

> Da ne spominjemo da ce imati znacajno manje interakcijskih problema jer
> ce svaka javusa imati svoj svijet koji ce joj izgledati tocno onakvim
> kakvim zamislja...

Ne vidim baďż˝ neku razliku u odnosu na chroot.

> [1] spomenuti grsec ce ti uz sve ostale prednosti i zabiljeziti koji proces
> je umro nenormalno (SIGILL, SIGSEGV, ...)

A ako �elim ne�to i napraviti u slu�aju smrti od signala? �to stvarno i
�elim za neke servise, ali ne i za ovu javu, tako da je pitanje �isto
iz znati�elje. Nije dodatni requirement. :-)

[Josip Almasi]

Drazen Kacar wrote:
>> - forka jedan logger proces (zato da blokiranje istog npr. disk full ne
>> blokira i system)
>> - salje stdout/stderr od javusa loggeru koji to zapisuje (preko pipe(2))
>

> Kad smo već kod toga, postoji li jedan od takvih loggera koji bi osim što
> piše po lokalnom disku znao te logove i pouzdano prenijeti preko mreže?

Yep, novi log daemoni oce preko tcp-a.
Samo pazi da ti remote log ne zbloka sistem:>

> Pouzdano okvirno znači da će u slučaju da receiver neko vrijeme ne radi

> logovi biti poslani kad proradi.

Jes, alociras mu neki lokalni send buffer.
Samo pazi da je dovoljno velik da se ne prepuni u to 'neko vrijeme':>

Pozdrav...

[Ivan Popovski]

Ne bacam oko na usenet tako cesto, pa.

On 2013-05-17, Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> Hm, ne djeluje mi zivahno s obzirom da je zadnji release iz 2011-e.
>
> http://lxc.sourceforge.net/index.php/news/

Ma mislim da je ovdje u pitanju userspace. Meni na slackwareu paket v0.7.5.

Dobra stvar je to sto, za razliku od drugih rjesenja, iza lxc stoje Google i
Linus osobno, a to znaci to sto znaci iliti vec neko vrijeme se nalazi u
standardnom kernelu. Isto tako ga mozes kombinirati sa cgroups-ima, pa imas
sansu kontrole resursa ako to zelis:

https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

Doduse, treba prvo vidjeti sto je sve implementirano u odredjenoj verziji
kernela, jer se sjecam da meni na jednoj verziji nije postojala podrska za
kontrolu kontejnerskog RAMa.

> Openvz djeluje zivlje, ali mi nije bas jasno koliko je to stabilno.

Jedino ako usporedjujes openvz sa aktivnoscu lxc userspacea.
Nisam bas siguran da ce se lxc userspace nesto mijenjati, stvar je odavno
dobro definirana.

Sto se tvoga problema tice osobno bi debootstrapnuo minimalnog debiana cca
5minuta i stavio javu unutra. Taj minimalni kontejner bi vjerojatno imao
svega par procesa (ako maknes getty i slicne gluposti iz inittaba koje ti
ne trebaju) sto je po meni cisce od nekakvih rjesenja tipa fork/exec.
Ali to je sada pitanje osobnog izbora.

E i da, kontejneri imaju svoj /proc ;-)

[Matija Nalis]

On Tue, 28 May 2013 05:21:38 +0000 (UTC), Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> Matija Nalis wrote:
>> On Mon, 20 May 2013 07:28:22 +0000 (UTC), Drazen Kacar <da...@fly.srk.fer.hr> wrote:

> Ali da, želim logirati.

>
>> Jer ako je to da zelis logirati, onda ce ti definitivno *morati* visiti
>> stalno neka scripta (jer tko ce zalogirati? ako ne mislis patchirati javu
>> ili bolje kernel[1]), pa ti je ta originalna "run" scripta bolje rjesenje
>> od neke druge nevezane run scripte. Ili ne vidim sto te muci?
>
> Visi runit. :-) Da budem precizniji, visi supervisor proces (runsv), a kad
> njegov servis ugine, on pokupi status i pozove skriptu finish koja onda
> taj status dobije (zajedno s brojem signala, ako je zbog toga proces
> izasao). Tako da u normalnim uvjetima finish skripta logira.

ah, to je razlika u odnosu na daemontoolse, tamo to radi run scripta nakon
izvrsenja programa. Ako ti to ovdje radi finish scripta, onda ti je puno
jednostavnije, jer cijeli taj dio ne moras brinuti.

sto ti onda tocno fali da prije "exec chroot ... java ..." pozoves:
burekscripta $pidfile $$ &

a burekscripta radi:
- trap alarm i postavi timeout
- iwatch da se pojavi pidfile iz $1
- ukoliko se pojavio pidfile, napravi umount i exita
- ukoliko je alarm timeoutao, zapise to u log, napravi umount i exita
(eventualno napravi "kill -9 $2" ili kakav god handling vec zelis za tu
javusinu ako je PPID isti kao i tvoj)

nema polanja, nema race conditiona, handlea i blokiranje javuse da ne kreira
pid kao i njen crash. Jel ti tu nesto fali?

>> "ps auxf" ce ti nacrtati nesto tipa:
>
> Aha. Nisam nikad koristio ps za takvo crtanje. Nisam ni znao da Linuxov ps

> to može. Obično koristim pstree za to.

tja, meni je pstree dosta beskoristan jer ne ispisuje skoro nista korisno
osim overviewa... Koristenje mi je obicno:

ps auxf | less +/nesto jer mi omogucuje da vidim i tree i context u kojem je
(tipa: aha, vidi od tih 230 apacheova mnogo ih je od ovog usera i trose hrpu
resursa jer su poforkali x CGIeva, koji vise na convert(1) jer svaki
pokusava konvertirati isto 50MB tiff u .ico :)

no, back on topic

>> ono gore je ljepse i citljivije od ovog dolje, to sam htio reci... (a i ima
>> manje potencijalnih problema kada zelis stopati proces sa runit ekvivalentom
>> "svc -d")
>

> Što jest - jest. Ako skripta ostane visiti, mora joj se implementirati da
> dobar dio signala hvata i prenosi svom djetetu. Što me baš ne oduševljava.

da, no nije tako strasno, imas trap i u shellu...
Naravno tu je jos i pitanje who will watch the watchers ako se doticna shell
scripta zblesi :)

>> > Tko mi garantira da u te dvije sekunde PID nece pripasti nekom
>> > novostvorenom procesu?
>>
>> na defaultnom Linuxu, tvoj hardver :) jer PID raste inkrementalno do
>> /proc/sys/kernel/pid_max, pa wraparounda tek onda. Vidi kernel/pid.c
>

> Ma da, ali... Tko mi garantira da se algoritam u pid.c neće promijeniti u
> skoroj budućnosti?

nitko; dapace ako instaliras ranije spomenuti GRSEC postati ce PIDovi
randomatski. Ali spomenuo si da ti nije portabilnost bas bitna, pa rekoh,
evo ti nesto sto radi..

ako zelis biti apsolutno siguran, naravno mozes provjeravati da li
/proc/$pid/stat ima apsolutno isti start_time kao na pocetku, pa te niti pid
reuse nece zeznuti da saznas da je bas javusha umrla i da je netko drugi
zauzeo njeno mjesto...

>> > State-of-the-art od prije 20 godina je nesto blokirajuce sto nece
>> > zahtijevati ekstra proces do kraja izvrsavanja Javetine. :-)
>>
>> state of the art ti je nekompatibilan sa runit tehnologijom, koja se bazira
>> na toj "run" scripti koju ti zelis eliminirati.
>

> Nije, na Solarisu bi lijepo funkcioniralo zato što tamo možeš čekati da
> bilo koji proces izađe, a ne samo tvoja djeca. Nema to veze s runit
> tehnologijom.

pa mozes i na Linuxu, samo sto ti ne volis PTRACE_ATTACH (a koji sluzi
upravo tome, da mozes vidjeti kada neki nevezani process dobije signal /
umre).

>> Nisam bas puno probavao, ali pogledaj rjesnja novija od sysvinit i
>> deaemontoolsa za managanje deamona, tipa upstart ili systemd ili sl.
>

> Mislim da neki od njih izvode ovo što bih ja htio upotrebom ptrace(2)
> poziva. Nisam baš oduševljen. A i nemam povjerenja u stabilnost.

pa, apt-get source systemd i "grep -i ptrace ." nalazi ptrace samo u dijelu
gdje dropa CAP_PTRACE capability :)

O nestabilnosti imas neke indicije ili?

>> Ili napravi svoju reimplementaciju ako te bas toliko veseli, nije
>> bas komplicirano (ali niti kompatibilno sa runitom bas) :
>
> A nije ni potrebno. -)
>
>> - forka jedan logger proces (zato da blokiranje istog npr. disk full ne
>> blokira i system)
>> - salje stdout/stderr od javusa loggeru koji to zapisuje (preko pipe(2))
>

> Kad smo već kod toga, postoji li jedan od takvih loggera koji bi osim što
> piše po lokalnom disku znao te logove i pouzdano prenijeti preko mreže?

multilog (ops, svlogd) i bilo koji pouzdani distribuirani filesystem koji ti
se svidja? ;)

> Pouzdano okvirno znači da će u slučaju da receiver neko vrijeme ne radi

> logovi biti poslani kad proradi.

za idealne vrijednosti "pouzdano", to znaci ili beskonacno memorije ili
beskonacno mjesta na disku.

recimo rsyslogd(8) navodno, sa RELP i bufferingom:
http://www.rsyslog.com/doc/rsyslog_reliable_forwarding.html

>> > Ali, kako rekoh, to je samo moj laicki i potencijalno paranoicni pogled na
>> > stvari.
>>
>> ili ako te vec vrti paranoja, vrti virtualku za svaku javusu i stavi je u
>> inittab(5), to ce ti biti znacajno sigurnije od chroota,
>

> Misliš? U chrootu nema pristupa procesima koji se izvršavaju s podignutim
> privilegijama, a u virtualci ima. Nije da ja želim maknuti proc iz chroota

zasto bi bilo? napravis barebones fs (dakle samo system sa
init, ili cak i bez njega, + java). nema nista suidano, ne vrti se niti
jedan proces osim jave (i eventualno inita, po zelji).

> da java ne bi vidjela koji se sve procesi izvršavaju, nego očekujem da će
> se naći kakav kernel bug u implementaciji koda koji čini proc, pa želim
> maknuti mogućnost interakcije s procom. U virtualci bi taj proc bio
> dostupan.

nije li sigurnije rekompajlirati javu da ne treba /proc?
sto ce joj to uopce? koliko sam shvatio to ti je feature jave kao takve,
(a ne same javusa aplikacije kojoj ne vjerujes in the first place)?
Kako brijem da java radi na OSevima koji /proc nemaju, zasto ga ne
eliminirati i tu?

>> a i ps(1) output ce izgledati cisto i stati na jedan ekran :)
> Aha. Oh, joy!

nije da ce unutra biti ikoga tko bi mogao pokrenuti ps(1), a niti samog
ps(1) :)

>> Da ne spominjemo da ce imati znacajno manje interakcijskih problema jer
>> ce svaka javusa imati svoj svijet koji ce joj izgledati tocno onakvim
>> kakvim zamislja...
>

> Ne vidim baš neku razliku u odnosu na chroot.

pa recimo, svaka instanca javuse moze imati neko svoju inkompatibilnost na
kojoj inzistira (npr. razlicite verzije javuse, librarya, kernela, OSova ...)

a dodatna razlika je sto eventualna provala u javu je vise izolirana (mozes
firewallati razlicite virtualne masine da mogu pristupati razlicitim network
resursima i sl).

>> [1] spomenuti grsec ce ti uz sve ostale prednosti i zabiljeziti koji proces
>> je umro nenormalno (SIGILL, SIGSEGV, ...)
>

> A ako želim nešto i napraviti u slučaju smrti od signala? Što stvarno i
> želim za neke servise, ali ne i za ovu javu, tako da je pitanje čisto
> iz znatiželje. Nije dodatni requirement. :-)

tail -F /var/log/kern.log | grep --line-buffered grsec...signalxxx | xargs -i nesto {} ?

ali obzirom trosis runit koji ima finish scriptu, ne vidim zasto ti je problem
to tamo handleati?