Custom Query (894 matches)

running "/etc/init.d/bcfg2-server stop" says: Stopping Configuration Management Server: * bcfg2-server

However, a "ps-ef | grep bcfg" still shows: "root 2440 1 0 19:52 ? 00:00:00 /usr/bin/python /usr/sbin/bcfg2-server -D /var/run/bcfg2-server.pid"

service bcfg2-server stop has the same effect.

/etc/init.d/bcfg2-server restart also doesn't stop the service which results in 2 processes running.

Hi,

After having set up certificate authentication (including multi-CA authentication, like I discussed on the mailing list), there is still one thing that bothers me (in addition to CRLs not being avalaible as emebedded python SSL support is now, but it is another matter) : text password does not seem to possibly be disabled - ever.

Wether I disable it in the bcfg2.conf on the server, or on the clients, even if certificate authentication works correctly (verified therebefore by setting a different password on the server and on the clients, whatever they are : connection indeed still works perfectly), the server issues me a :

"No authentication data presented Authentication Failure"

in its log. Well, as said, if I set some password, even if the server and the client ones do not tie in, I authenticate perfectly well anyway with certificates : well, yes - certificates _are_ authentication data (and valid ones are even legit).

I for one do not only want to authenticate using certificates, but even be sure passwords are never ever used : I don't need them, I don't want them. In the meantime this bug gets corrected (using Debian to evaluate bcfg2 for now, even with Debian Squeeze which is the recently frozen Testing, this will not be corrected anytime soon in the stable flavor of my favorite distro, so, I settled on this workaround for now), I decided I will use a very long and complex global password on the server, and a bogus one on the clients (in case one of them gets compromised, and the password is leaked, this password would be of no use whatsoever ; having to manage a bogus server password is a bugger nonetheless, though, as whatever its length, it reduces the server's thoughness against unwanted breakins, in respect with a valid certificate as the only way through) - but this should really be corrected, IMHO : "No authentication data presented" should only be answered if, indeed, none has been - and in the case of certificate authentication, well : more than some has actually been, as a far better one than a bad-ol' symetric password has indeed been presented (actually, a password is no kind of authentication, but rather an authorization mean, whereas a user name is an authentication mean, and a certificate associated with its private key is both - would one want to be precize : telling who somebody presents himself as, and if she is authorized to go through, those are two very distinct notions).

Please allow for certificate authentication to be sufficient, and for ditching any kind of text password use if one wants to (I concur with the idea that if neither a password, nor a certificate, nor anything has been presented, connection should be refused by default - other people might need systematic connection authorization, though, but I guess this should be the case for another explicit option, such as "always-allow = true").

Regards.

Code snippet (which doesn't follow PEP8, btw; ugly linebreaks added by me):

163     except getopt.GetoptError, mesg:
164         # print help information and exit:
165         print "%s\nUsage:\nbcfg2-build-reports
 [-h]
[-A (include ALL clients)]
 [-c <configuration-file>]
 [-s <statistics-file>]
[-N (do not ping clients)]" % (mesg)
166         raise SystemExit, 2
167     for o, a in opts:
168         if o in ("-h", "--help"):
169             print "Usage:\nbcfg2-build-reports
 [-h]
 [-c <configuration-file>]
 [-s <statistics-file>]"
170             raise SystemExit

The manual page also documents only part of the options.