Re: Trigger in package meerdere keren uitgevoerd
Op 20101029 om 14:11 schreef Martijn Grendelman:
> On 28-10-10 16:34, Geert Stappers wrote:
> > Op 20101028 om 15:13 schreef Martijn Grendelman:
<knip/>
> >> als er dan vervolgens iets misgaat tijdens de configuratie, dan krijg je:
> >>
> >> E: Sub-process /usr/bin/dpkg returned an error code (1)
> >> A package failed to install. Trying to recover:
> >> Setting up <pakketnaam> (<versie>).
> >>
> >> en vervolgens wordt de trigger /nog een keer/ uitgevoerd.
> >>
> >> Hoe kan ik ervoor zorgen, dat de trigger maar EEN keer wordt uitgevoerd?
> >>
> >
> > Als ik het goed lees, zijn er twee packages gemaakt en is er een
> > verwijzig van het ene package naar het andere package.
>
> Correct.
>
> > Mijn verzoek is om het "probleem E-mailtje" nog een keer te schrijven.
> > En dan de (fictieve) package namen gebruiken. Zodat ook echt duidelijk
> > wordt dat er meerdere packages in het spel zijn.
>
> Ok.
>
> Ik gebruik Puppet om mijn firewall te beheren. Nou ben ik een pakket (noem
> het 'xyz') aan het maken, dat een service installeert, waarvoor er een
> gaatje in de firewall moet worden geprikt. Het pakket levert zelf de
> firewall rules aan in een file, en na installatie moet Puppet een 'reload'
> krijgen, om de firewall te reloaden met de nieuwe rules.
>
> Ik heb daarom in Puppet een trigger gedefinieerd, genaamd 'puppet-reload'.
> In de 'triggers' file van Puppet staat:
[1]
>
> interest puppet-reload
>
> In de triggers file van mijn pakket 'xyz' staat:
>
> activate puppet-reload
>
> > Plus: SHOW US THE SOURCE CODE!
> >
> > Op zijn minst de post install files en de triggerscripts.
>
> Dat had ik toch al grotendeels gedaan. De code in het postinst script is
> niet relevant, want die werkt gewoon, maar voor de volledigheid:
>
> if [ "$1" = "triggered" ]; then
> invoke-rc.d puppet reload || true
> fi
>
> Het probleem is dus, dat tijdens een installatie met aptitude deze code
> twee keer wordt uitgevoerd, terwijl ik dat eigenlijk maar 1 x zou willen.
>
> Bij installatie met 'dpkg -i' treedt dit probleem niet op.
>
> Is dit een bug in Apt(itude)?
Waar de bug zit is mij nog niet duidelijk.
En eigenlijk is het mij het probleem nog niet duidelijk.
Ik ben van mijn mening dat de winst te halen is
in een goede omschrijving van het probleem.
Misschien moeten we ons ook wel focussen op de oorspronkelijke wens:
Een nieuwe service achter de firewall moet bereikbaar worden.
Mijn inschatting is dat een "ssh server" en een "http server"
_niet_ tegen Puppet aanschoppen (die op zijn beurt tegen de firewall
schopt )
Enfin, terug naar het trigger probleem.
> >> E: Sub-process /usr/bin/dpkg returned an error code (1)
> >> A package failed to install. Trying to recover:
> >> Setting up <pakketnaam> (<versie>).
Wat is <pakketnaam> in bovenstaande situatie? "Puppet" of "xyz" ???
> if [ "$1" = "triggered" ]; then
> invoke-rc.d puppet reload || true
> fi
In welk package zit die programma code ??
Ik ben mij er van bewust dat ik nog alleen maar vragen aan het stellen
ben. Maar ja, ik had ook al gezegd dat het probleem mij niet duidelijk
is. En jullie zien vast wel dat er nog mee gedacht wordt door mij.
Tussen de regels door heb ik gelezen[2] dat
dpkg -i xyz_0.02_all.deb
goed gaat. Ik heb echter graag de output van dat commando.
En het schijnt[3] dat
aptitude install xyz
misgaat. Daar ook graag de output van.
Groeten
Geert Stappers
Voetnoten
[1] Ik lees het als een "puppet trigger". Dit gaat toch over package
triggers???
[2] Alleen 'dpkg -i' was te lezen. De rest heb ik moeten verzinnen.
Ik stel het erg op prijs dat hele commandoregels getoond worden.
[3] Alleen "Apt(itude)" kwam voorbij. De rest heb ik moeten verzinnen.
Ik stel het erg op prijs dat hele commandoregels getoond worden.
Reply to: