a small comment on isc dhcp

[Simon Hobson]

Luc T. wrote:

>I do think it is more important to start the service even with minor 
>mistakes than just stucking there (For example, if duplicate host 
>names are found, rather than stucking there, one of them can be 
>chosen and others ignored).

How do you define 'minor' ? What is minor to some may be major to 
others. I think you would be complaining VERY loudly if it started 
with what the authors thought was a minor error and it screwed your 
network !


>   It is understood that test option can be used to check the 
>syntax.What if one is modifying the files, and the other is 
>restarting the service (assuming that the first person began 
>modifying configuration files right after the other has finished 
>check syntax)?

If you do not have some interlocks in place then you are assured of 
some REALLY odd happenings ! You REALLY should have a system in place 
where only one person can be 'working' on the configuration - where 
'working' means the interval between starting to edit the config file 
and either starting the server with the new config or backing out any 
changes.

What you must NOT be able to do is start editing the file while 
someone else is still restarting the server - that is a recipe for it 
getting started with changes half-done. Eg, if someone edits the 
file, saves it while they look something up, then the server gets 
restarted by someone who made a prior change - that will result in 
attempting to start the server with a change half done.

You need a process like this :
Apply a lock
Edit config file
Test config, go back and re-edit if required
Stop server
Start server
Remove lock

While the lock is set then no other person should be able to edit the 
config file or start/stop/restart the server. That is normal practice 
where several people are able to alter configs. Lock may be a 
technical one (lock files and scripts for example), or it may be a 
procedural one (though that is less reliable).


In this case I think you should be looking at your own processes, not 
blaming the software.