[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: update-rc.d vraagje



Vincent Zweije schreef:
> On Thu, Dec 02, 2010 at 11:37:09PM +0100, Paul van der Vlis wrote:
> 
> ||  Ik heb een simpel firewall script wat ik altijd start vanuit init.d.
> ||
> ||  Het init.d-script heb ik aangepast aan de LSB regels voor Squeeze en ik
> ||  gebruik dependency based booten.
> ||
> ||  Maar ik snap update-rc.d wellicht niet helemaal:
> ||  -------------
> ||  root@debian:~# update-rc.d firewall start 12 2 3 4 5 .
> ||  update-rc.d: using dependency based boot sequencing
> 
> Deze mededeling betekent dat de boot-volgorde wordt bepaald door de
> afhankelijkheden die in het script zelf zijn genoemd. De prioriteit die
> je zelf opgeeft (12) wordt genegeerd.
> 
> Je zult ooit dependency-based boot hebben geactiveerd. 

Het is een nieuwe installatie, en daar is het default.

> Het is nu zaak
> de prioriteiten in je script zelf goed te zetten.

Ik had er oorspronkelijk alleen in staan dat hij moest wachten op syslog.

> Zo heb ik bijvoorbeeld in /etc/init.d/firewall:
> 
>     ### BEGIN INIT INFO
>     # Provides:          firewall
>     # Required-Start:    $network
>     # Required-Stop:
>     # Default-Start:     S
>     # Default-Stop:      0 6
>     # Short-Description: Firewall rules
>     # Description:       Set up the iptables firewall rules in the kernel
>     # X-Start-Before:    $networking
>     # X-Stop-After:      $networking
>     ### END INIT INFO
> 
> ||  root@debian:~# ls /etc/rc2.d/*firewall
> ||  /etc/rc2.d/S18firewall
> 
> 18 is dus wat er uit de afhankelijkheidsanalyse (door update-rc.d)
> kwam rollen.

Bedankt, het gaat nu bij mij ook goed, vooral die "X-Start-Before" deed
het hem.

Ik gebruik nu overigens dit commando om het in werking te zetten:
update-rc.d firewall defaults

Hij geeft dan wel wat warnings, maar ik hoef verder niet na te denken
over het commando (hij voert toch uit wat in de initscripts staat, dus
juiste commando's hebben weinig zin).

Met vriendelijke groet,
Paul van der Vlis.




-- 
http://www.vandervlis.nl/


Reply to: