Custom Query (894 matches)

bcfg2-server seems to allow multiple instances to be listening on the same port. (I didn't know this was even possible!) This might cause confusion.

How to reproduce (at least on my debian etch with svn build 2531):

1. Start bcfg2-server: # /etc/init.d/bcfg2-server start

2. Start bcfg2-server manually: # bcfg2-server &

3. See netstat output:

# netstat -plunt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 x.x.x.x:6789          0.0.0.0:*               LISTEN     3909/python
tcp        0      0 x.x.x.x:6789          0.0.0.0:*               LISTEN     3906/python
(...)

How to fix: bcfg2-server should detect the situation where someone is already listening on the port and refuse to start.

When testing bcfg2, I occasionally get errors such as

Incomplete information for entry ConfigFile:/etc/motd; cannot install

and on respectively on the server:

Failed to bind entry: ConfigFile /etc/motd

It took me a while to realize that this occurs when I've just restarted the bcfg2-server and then run the client too quickly.

How to reproduce:

1. Start the server: # bcfg2-server

2. The server says: "Bound to port 6789" but no lines telling "Processed 3 gamin events..." yet.

3. Run the client.

4. See the server output

A correct run:

# bcfg2-server
/etc/bcfg2.pem
Bound to port 6789
Processed 23 gamin events in 6.161 seconds. 0 collapsed
Processed 3 gamin events in 0.100 seconds. 0 collapsed
Processed 3 gamin events in 0.100 seconds. 0 collapsed
Generated config for etchbase in 0.0238389968872 seconds
Client etchbase reported state clean

An incorrect run:

# bcfg2-server
/etc/bcfg2.pem
Bound to port 6789
Processed 23 gamin events in 6.081 seconds. 0 collapsed
Processed 3 gamin events in 0.101 seconds. 0 collapsed
Failed to bind entry: ConfigFile /etc/motd
Generated config for etchbase in 0.024423122406 seconds
Processed 3 gamin events in 0.101 seconds. 0 collapsed
Client etchbase reported state dirty

How to fix: the server should first read the config and only then start listening on the port.

When running bcfg2 -I, the "-r all" seems to be implied. IMO, running without -I should result in the same condition as running with -I and answering "y" to every question.

How to fix: -I should not imply "-r all".