1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
|
<?xml version='1.0' encoding="UTF-8"?>
<!--
Sync: 1.7
-->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/nl/rc-scripts.xml">
<title>Gentoo Linux 1.0 Init Systeem</title>
<author title="Author">
<mail link="azarah@gentoo.org">Martin Schlemmer</mail>
</author>
<author title="Proof-reader">
<mail link="seemant@gentoo.org">Seemant Kulleen</mail>
</author>
<author title="Translator">
<mail link="swift@gentoo.org">Sven Vermeulen</mail>
</author>
<license/>
<abstract>
Deze handleiding is een introductie tot Gentoo Linux' Init systeem,
en beschrijft tevens enkele zaken ivm met schrijven van rc-scripts.
</abstract>
<version>1.0.2</version>
<date>30 April 2003</date>
<chapter>
<title>Inleiding</title>
<section>
<body>
<p>
Gentoo Linux gebruikt een initsysteem dat vooral gecontroleerd wordt door
afhankelijkheden (<e>dependencies</e>). Ze is eenvoudig in onderhoud, maar
toch krachtig en flexibel genoeg voor eender welke opstelling.
Deze handleiding mag niet beschouwd worden als een introductie tot de interne
werking van het systeem; eerder is deze een snelle handleiding over hoe je het
Gentoo's initsysteem klaar en draaiende krijgt.
Voor diegenen die geinteresseerd zijn in de interne werking: lees de broncode
:)
</p>
</body>
</section>
</chapter>
<chapter>
<title>Runlevels</title>
<section>
<body>
<p>
In tegenstelling tot andere initsystemen maakt Gentoo's initsysteem geen
gebruik van vreemde namen of nummers, maar eerder van eigengedefinieerde namen
die vertaald worden naar de standaard runlevelnummers van init.
</p>
<note>
Per default zijn er 3 runlevels, namelijk <e>"boot"</e>,
<e>"default"</e> en <e>"nonetwork"</e>.
</note>
<p>
De <e>"boot"</e> runlevel is default bij de meeste configuraties, en
zoals de naam al laat vermoeden is het deze runlevel die uitgevoerd wordt
tijdens het booten. De volgende is <e>"default"</e> die, zoals de
naam al laat vermoeden, uitgevoerd wordt na de boot-runlevel. De laatste is
<e>"nonetwork"</e> die eigenlijk puur een voorbeeldrol speelt.
</p>
<p>
De runlevels bevinden zich in <path>/etc/runlevels</path>, in een submap
genoemd naar de runlevel; deze submap is gevuld met symlinks naar services die
door de runlevel opgestart worden.
</p>
<note>
De aangeraden manier om services toe te voegen of te verwijderen staat in de
sectie "Utilities / help-scripts".
</note>
<p>
Zoals al eerder werd vermeld kan de naam van de runlevel aangepast worden naar
eender welke term de gebruiker wenst, maar men mag niet vergeten
<path>/etc/inittab</path> mee te wijzigen om de aanpassing door te voeren.
</p>
<warn>
Een uitzondering is de <e>"boot"</e> runlevel die NOOIT mag hernoemd
worden, aangezien dat leidt tot defecte werking van je systeem.
</warn>
<p>
De <path>/sbin/rc</path> script leidt al dit in goede banen, en kan uitgevoerd
worden om direct tussen verschillende virtuele runlevels te switchen.
</p>
</body>
</section>
<section>
<title>Virtuele runlevels</title>
<body>
<p>
Aangezien de runlevels niet statisch gemapped worden aan deze van init kan je
meer runlevels aanmaken dan dat er nummers bij init voorhanden zijn.
Hierdoor kan de gebruiker profielen of virtuele runlevels aanmaken afhankelijk
van de situatie.
</p>
<p>
Bijvoorbeeld, een laptop gebruiker kan 2 default runlevels hebben, genaamd
"online" en "offline". Hierdoor kan men een actieve
runlevel hebben voor wanneer de PCMCIA netwerkkaart ingeplugged is, en een
voor wanneer deze netwerkkaart niet ingeplugged is. De PCMCIA-scripts kunnen
geconfigureerd worden om, afhankelijk van de situatie,
<c>"/sbin/rc online"</c> respectievelijk
<c>"/sbin/rc offline"</c> uit te voeren, dit om de correcte services
te laden afhankelijk van de aanwezigheid van de netwerkkaart.
</p>
</body>
</section>
<section>
<title>Runlevels en XFree86</title>
<body>
<p>
Gentoo heeft geen aparte runlevel expliciet voor het grafisch opstarten, maar
enkel een rc-script (initscript) die dat toelaat. Deze heet, zoals bij de
meeste andere distributies, "xdm" en kan aan eender welke runlevel
toegevoegd worden indien de gebruiker dat wenst.
</p>
<warn>
"xdm" toevoegen aan de boot runlevel kan resulteren in
ongewenste werking van het systeem!
</warn>
<p>
Per default, als je xdm, gdm of kdm wilt uitvoeren alvorens de gettys gestart
worden, zal X starten op de eerste vrije console. Bij tragere machines is dit
geen probleem indien de Desktop Manager service pas op het einde van de
bootsequentie opgestart wordt. De gettys zullen starten voordat X start
en deze laatste zal zich dus binden aan console 7 zoals gewenst.
Bij snellere machines is dit echter niet het geval. X zal starten alvorens de
gettys gestart zijn (gewoonlijk op console 2). Wanneer de gettys starten, nemen
deze de controle over van het keyboard en verliest de Desktop Manager
keyboardondersteuning.
</p>
<p>
Dit kan opgelost worden door de Desktop Managers' opstartscript in een
extra runlevel te plaatsen, namelijk 'a'. Aangezien 'a' geen echte runlevel
is dient onze "xdm" script enkel <c>"telinit a"</c> op te
starten. Hierdoor zullen alle services in runlevel 'a' uitgevoerd worden
<i>nadat</i> de services in de huidige runlevel uitgevoerd zijn, dus wanneer
alle gettys opgestart zijn.
</p>
<note>
Meer informatie over runlevel 'a' krijg je door init's manpage te
lezen.
</note>
</body>
</section>
</chapter>
<chapter>
<title>RC-Scripts</title>
<section>
<body>
<p>
rc-scripts zijn scripts die de basis-functies van elke service definieren,
inclusief afhankelijkheden voor opstarten en afsluiten. Ze bevinden zich in
<path>/etc/init.d</path>
</p>
</body>
</section>
<section>
<title>Basis layout van een rc-script</title>
<body>
<pre caption="rc-script layout">
#!/sbin/runscript
depend() {
need bar
}
start() {
ebegin "Starting foo"
/sbin/foo
eend $? "Failed to start foo"
}
stop() {
ebegin "Stopping foo"
kill $(cat /var/run/foo.pid)
eend $? "Failed to stop foo"
}
</pre>
<note>
De interpreter is "/sbin/runscript". De "depend"
functie is optioneel. Alle rc-scripts moeten minstens de "start"
functie hebben.
</note>
</body>
</section>
<section>
<title>Opstarten controleren</title>
<body>
<p>
De algemene opstartvolgorde van de services in een runlevel is alfabetisch. Dit
komt wegens de uitvoer van <path>/bin/ls</path>.
</p>
<p>
De eerste methode om van de default opstartvolgorde af te wijken zijn
afhankelijkheden. Indien er geen relatie is tussen services kan het order-type
gebruikt worden.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Dependency types</title>
<section>
<body>
<p>
De meeste services zijn gerelateerd of hangen af van een andere service.
</p>
<p>
Postfix bijvoorbeeld vereist een draaiende "network", alsook een
system logger.
</p>
<p>
Samba aan de andere hand vereist dat "network" draaiende is, maar
indien CUPS gebruikt wordt voor het printen moet deze opgestart worden voordat
samba gestart wordt. Merk echter op dat cups niet expliciet noodzakelijk is
voor het opstarten van samba.
</p>
<p>
We hebben dus 2 manieren om afhankelijkheidsrelaties (<e>dependencies</e>)
tussen verschillende services uit te drukken. Deze afhankelijkheden zijn altijd
geldig, ook al is de runlevel compleet aangepast of een service manueel
gestart/gestopt na het booten.
</p>
</body>
</section>
<section>
<title>De NEED afhankelijkheid (dependency)</title>
<body>
<p>
Deze wordt gebruikt indien een service noodzakelijk is voor het opstarten van
de huidige service.
</p>
<pre caption="Toevoegen van logger en net als een NEED afhankelijkheid">
depend() {
need net logger
}
</pre>
<note>De service vermeld na <e>NEED</e> is noodzakelijk voor het opstarten van
de service. Deze service zal dus niet opstarten indien een van zijn
NEED-afhankelijkheden niet opstart.
</note>
<impo>
Indien een service aan een <e>NEED</e>-regel is toegevoegd zal deze opgestart
worden, onafhankelijk van het feit of deze service in de huidige runlevel (of
in de "boot" runlevel) gedefinieerd is of niet.
</impo>
<p>
<e>NEED</e> is dus een "dominante" afhankelijkheid.
</p>
</body>
</section>
<section>
<title>De USE afhankelijkheid</title>
<body>
<p>
De service die door de use-afhankelijkheid vermeld wordt is niet noodzakelijk
voor het opstarten van de huidige service, maar indien ze opgestart wordt moet
dat voordien gebeuren.
</p>
<pre caption="Toevoegen van portmap als een USE afhankelijkheid aan netmount">
depend() {
use portmap
}
</pre>
<p>
Netmount kan per default gebruik maken van NFS mounts, maar zal enkel afhangen
van portmap indien deze toegevoegd is aan de huidige runlevel (of de
"boot"-runlevel). Indien je dus wenst dat NFS-mounts ondersteund
worden moet je dus portmap toevoegen aan de default runlevel, zodat netmount
portmap ziet als een afhankelijkheid en deze dus eerder laat opstarten.
</p>
<impo>
Een service in de <e>USE</e> regel <e>moet</e> toegevoegd worden aan de
huidige runlevel (of de boot runlevel) opdat deze als een geldige
afhankelijkheid gezien wordt.
</impo>
<p>
<e>USE</e> is dus een "voorbehouden" afhankelijkheid.
</p>
<note>
Indien een service in een <e>USE</e> regel niet foutloos start, zal de huidige
service toch starten, aangezien de service in de <e>USE</e> regel niet
noodzakelijk is.
</note>
</body>
</section>
</chapter>
<chapter>
<title>Zonder afhankelijkheden toch de volgorde controleren</title>
<section>
<body>
<p>
Indien geen afhankelijkheidsrelatie bestaat tussen 2 services, maar het gewenst
is dat de ene voor de andere opstart, dan kan men gebruik maken van de
<e>AFTER</e> en de <e>BEFORE</e> afhankelijkheden.
</p>
<note>
Deze 2 types zijn enkel geldig tussen verschillende runlevels.
</note>
<p>
Optioneel kan men gebruik maken van de "*" glob voor het aanduiden
van alle andere services:
</p>
<pre caption="Een glob example voor AFTER in de local-initscript">
depend() {
after *
}
</pre>
<p>
Dit zorgt ervoor dat local gestart wordt <e>na</e> alle andere services.
</p>
</body>
</section>
<section>
<title>De BEFORE volgorde-variabele</title>
<body>
<p>
De huidige service moet gestart worden <e>voor</e> de services vermeld in de
<e>BEFORE</e> regel.
</p>
<pre caption="Zorgt ervoor dat foo start voor bar (in foo-initscript)">
depend() {
before bar
}
</pre>
</body>
</section>
<section>
<title>De AFTER volgorde-variabele</title>
<body>
<p>
De huidige service moet gestart worden <e>na</e> de services vermeld in de
<e>AFTER</e> regel.
</p>
<pre caption="Zorgt ervoor dat bar start na foo (in bar-initscript)">
depend() {
after foo
}
</pre>
</body>
</section>
</chapter>
<chapter>
<title>Virtuele services</title>
<section>
<body>
<p>
Services, zoals de meeste andere zaken in de Unix-wereld van vandaag, komen in
verschillende smaken en kleuren. Het is meestal de keuze van de
systeembeheerder die beslist welke servicetool er gebruikt wordt.
</p>
<p>
System loggers zijn een van die voorbeelden. Op het moment van schrijven bevat
Gentoo Linux een 4-tal verschillende system loggers waaruit de gebruikers
kunnen kiezen. Alle services die een system logger vereisen voordat ze zelf
opstarten kunnen onmogelijk alle 4 de loggers in de <e>NEED</e> steken. Maar
<e>USE</e> is te zwak aangezien een werkende system logger noodzakelijk is.
</p>
<p>
Dit is waar virtuele services en de <e>PROVIDE</e> types hun intrede doen.
</p>
</body>
</section>
<section>
<title>Het PROVIDE type</title>
<body>
<p>
Het <e>PROVIDE</e> type definieert een virtuele service die andere services
kunnen <e>NEED</e>'en of <e>USE</e>'en.
</p>
<pre caption="sysklogd die logger PROVIDEs">
depend() {
provide logger
}
</pre>
</body>
</section>
<section>
<title>De LOGGER virtuele service</title>
<body>
<p>
<e>LOGGER</e> is een voorgedefinieerde virtuele service die door alle system
loggers gecreeerd wordt. Ze kan gebruikt worden met <e>NEED</e> of <e>USE</e>
afhankelijkheidstypes.
</p>
</body>
</section>
<section>
<title>De NET virtuele service</title>
<body>
<p>
De <e>NET</e> service is een andere virtuele service, maar in tegenstelling tot
<e>LOGGER</e> omvat het niet 1 expliciete service.
</p>
<impo>
Om de <e>NET</e> virtuele service te voorzien (PROVIDE) moet:
<ul>
<li>de service toegevoegd worden aan de huidige of de boot runlevel.</li>
<li>zijn naam beginnen met "net.".</li>
<li>zijn naam eindigen met de naam van een bestaande netwerk-interface
(bijvoorbeeld net.eth0 of net.ppp1).</li>
</ul>
</impo>
<p>
Voor elke net.* service zal $IFACE gedefinieerd zijn met de naam van
de netwerkinterface (bijvoorbeeld "eth0" voor net.eth0).
</p>
</body>
</section>
</chapter>
<chapter>
<title>Default commandoregelopties</title>
<section>
<body>
<p>
Elke service kan opgeroepen worden met een van de default opties. Alle vermelde
opties zijn automatisch beschikbaar, behalve <e>START</e> en <e>STOP</e> die de
gebruiker zelf moet definieren in zijn rc-script.
</p>
<impo>
De <e>start()</e> functie <e>moet</e> gedefinieerd zijn.
</impo>
<note>
De <e>stop()</e> functie is minder belangrijk en kan worden
weggelaten.
</note>
<note>
In het algemeen zal de gebruiker enkel <e>start()</e>, <e>stop()</e> en
<e>restart()</e> definieren. De rest is intern en dient met rust gelaten te
worden.
</note>
<pre caption="start de httpd service">
# <c>/etc/init.d/httpd start</c>
</pre>
<note>Commandoregelopties kunnen gemengd voorkomen.</note>
<pre caption="pause/start net.eth0">
# <c>/etc/init.d/net.eth0 pause start</c>
</pre>
</body>
</section>
<section>
<title>De START/STOP opties</title>
<body>
<p>
<e>START</e> de service inclusief de services waarvan deze afhangt.
</p>
<p>
<e>STOP</e> de service inclusief de services die ervan afhangen.
</p>
</body>
</section>
<section>
<title>De RESTART optie</title>
<body>
<p>
De service moet gestart zijn alvorens dat <e>RESTART</e> zal werken. Het zal de
service herstarten alsook alle services die ervan afhangen.
</p>
<note>
Indien een eigen <e>restart()</e> functie gedefinieerd is moet de
gebruiker <e>"svc_start()"</e> en <e>"svc_stop()"</e>
gebruiken om de service te starten respectievelijk te stoppen. Dit is
noodzakelijk om de afhankelijkheden correct te doen verlopen.
</note>
</body>
</section>
<section>
<title>De PAUSE optie</title>
<body>
<p>
Deze zal de service stoppen, maar in tegenstelling tot <e>STOP</e> zullen de
services die ervan afhangen met rust gelaten worden.
</p>
</body>
</section>
<section>
<title>De ZAP optie</title>
<body>
<p>
Deze zet de status van de service naar "gestopped".
</p>
<note>
Merk op dat geen enkel van de commando's in de <e>stop()</e> functie
uitgevoerd worden. De gebruiker zal er dus zelf voor moeten zorgen dat de
service-daemons etc... gestopt zijn (bijvoorbeeld dmv killall).
</note>
</body>
</section>
<section>
<title>De INEED/NEEDSME opties</title>
<body>
<p>
<e>INEED</e> geeft de services weer die deze service in zijn <e>NEED</e> regel
staan heeft.
</p>
<p>
<e>NEEDSME</e> geeft de services weer die deze service in hun <e>NEED</e> regel
staan hebben.
</p>
</body>
</section>
<section>
<title>De IUSE/USESME opties</title>
<body>
<p>
<e>IUSE</e> geeft de services weer die deze service in zijn <e>USE</e> regel
staan heeft.
</p>
<p>
<e>USESME</e> geeft de services weer die deze service in hun <e>USE</e> regel
staan hebben.
</p>
</body>
</section>
<section>
<title>De BROKEN optie</title>
<body>
<p>
Deze toont de services die vermist zijn (indien van toepassing) en die wel
in de <e>NEED</e> regel staan vermeld.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Eigen commandoregelopties toevoegen</title>
<section>
<body>
<p>
Het is relatief gemakkelijk om eigen commandoregelopties toe te voegen. Een
functie met als naam de gewenste commandoregeloptie dient te worden
gedefinieerd in de rc-script, en moet toegevoegd worden aan de <e>$opts</e>
variabele, zoals in het onderstaande voorbeeld:
</p>
<pre caption="foo als een eigen optie">
opts="${opts} foo"
foo() {
............
}
</pre>
</body>
</section>
</chapter>
<chapter>
<title>Configuratie</title>
<section>
<body>
<p>
Configuratie van rc-scripts dient algemeen te gebeuren via
omgevingsvariabelen. Deze mogen echter niet in de rc-script gedefinieerd
worden, maar in een van de 3 mogelijke configuratiebestanden.
</p>
<p>
De eerste is specifiek aan het rc-script, de andere zijn 2
globale configuratiebestanden.
</p>
<pre caption="configuratiebestanden voor rc-scripts">
<path>/etc/conf.d/<naam van rc-script></path>
<path>/etc/conf.d/basic</path>
<path>/etc/rc.conf</path>
</pre>
<note>
Deze 3 configuratiebestanden worden automatisch ingelezen in diezelfde
volgorde.
</note>
<impo>
De <e>NET</e> services lezen tevens <path>/etc/conf.d/net</path>
in.
</impo>
</body>
</section>
</chapter>
<chapter>
<title>Utilities / help-scripts</title>
<section>
<title>Het rc-update tool</title>
<body>
<p>
rc-update is de primaire tool om services toe te voegen aan en te verwijderen
uit een runlevel. Deze zal tevens "depscan.sh" uitvoeren om de
afhankelijkheidsinformatie te vernieuwen.
</p>
<pre caption="Voeg metalog toe aan de default runlevel">
# <c>rc-update add metalog default</c>
</pre>
<pre caption="Verwijder metalog uit de default runlevel">
# <c>rc-update del metalog default</c>
</pre>
<note>
Indien je rc-update zonder argumenten uitvoert krijg je meer informatie.
</note>
</body>
</section>
<section>
<title>Het depscan.sh-script</title>
<body>
<p>
Voor de volledigheid vermelden we hier depscan.sh. Deze wordt gebruikt om een
afhankelijkheidlijst op te stellen die bestaat uit de afhankelijkheden die door
de services vermeld worden.
</p>
<p>
depscan.sh moet uitgevoerd worden telkens er een nieuwe rc-script toegevoegd
wordt aan <path>/etc/init.d</path>, maar aangezien rc-update dat zelf al doet
moeten de meeste gebruikers zich hier niets van aantrekken.
</p>
</body>
</section>
</chapter>
</guide>
|
GitWeb