Custom Query (894 matches)
Results (106 - 108 of 894)
Ticket | Owner | Reporter | Resolution | Summary |
---|---|---|---|---|
#1127 | https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc | Michael Fincham <[email protected]…> | fixed | SSLCA certificate validation is being carried out with the CA specified as `untrusted' |
Description |
On my installation SSLCA managed certificates are only valid during the client run in which they are created, subsequent runs declare the certificate as invalid and delete it. I see that diff:src/lib/Server/Plugins/[email protected]:f379b0e43cfa0137379ad0f78f48223eba7db61a on line 187 the way openssl is called was changed:
+ res = Popen(["openssl", "verify", "-untrusted", chaincert, "-purpose", + "sslserver", cert], This seems to cause validation of the stored cert to always fail: Aug 27 18:26:48 manager bcfg2-server[29849]: SSLCA: /etc/stunnel/mysql-client-cert.pem failed verification against CA: /var/lib/bcfg2/SSLCA/etc/stunnel/mysql-client-cert.pem/mysql-client-cert.pem.H_test.example.com: /C=NZ/O=Example/CN=example.com#012error 19 at 1 depth lookup:self signed cer Changing "-untrusted" back to "-CAfile" allows validation to succeed: SSLCA/etc/stunnel/mysql-client-cert.pem/mysql-client-cert.pem.H_test.example.com: OK Is there some reason I can't discern for why this was changed to "-untrusted"? |
|||
#1009 | desai | Michael Laß <[email protected]…> | fixed | bcfg2-server sends data that is not properly encoded |
Description |
When trying to deploy files with special chars in it (like german umlauts (ä, ö, ü, ..)) I get tracebacks on the client. I have attached two files containing the output of bcfg2-client. bcfg2-error-w-lxml.log: Output when python-lxml is installed bcfg2-error-wo-lxml.log: Output when python-lxml is not installed The file which should be deployed is UTF-8 encoded. Server and client have set 'encoding = utf-8' in their configurations. I'm using bcfg2-server 1.1.1 on a Debian lenny machine. On client side I can reproduce the problem with Debian lenny, squeeze and Ubuntu natty without python-lxml installed, but only on Ubuntu natty with python-lxml installed. So versions of python-lxml older than 2.3 seem to avoid this problem somehow... I have also attached a patch for the client which solves the problem. But I think this is only a workaround and the real problem is on server side because the XML data should be encoded correctly before it is sent to the client. |
|||
#695 | desai | Mike McCallister <[email protected]…> | fixed | bcfg2-server should log CoreInitExceptions to syslog |
Description |
In upgrading my configuration from 0.9.5.7 to ~1.0 pre5 (r5389), I missed the need to have a Metadata plugin in my bcfg2.conf file. When I started bcfg2-server using the init script, it exits with no indication of an error in syslog or anywhere else I can see. When I run it in debug mode from the console, I see the following traceback: Traceback (most recent call last): File "/usr/sbin/bcfg2-server", line 64, in ? ca=setup['ca'], File "/usr/lib/python2.4/site-packages/Bcfg2/Component.py", line 60, in run_component component = component_cls(**cls_kwargs) File "/usr/lib/python2.4/site-packages/Bcfg2/Server/Core.py", line 83, in __init__ raise CoreInitError, "No Metadata Plugin" Bcfg2.Server.Core.CoreInitError: No Metadata Plugin My expectation is that when run in daemon mode, even (or especially) fatal errors should be logged to syslog if at all possible. Something like this might work for CoreInitException: try: Bcfg2.Component.run_component(Bcfg2.Server.Core.Core, location=setup['location'], daemon = setup['daemon'], pidfile_name = setup['daemon'], protocol = setup['protocol'], register=False, cls_kwargs={'repo':setup['repo'], 'plugins':setup['plugins'], 'password':setup['password'], 'encoding':setup['encoding'], 'ca':setup['ca'], 'filemonitor':setup['fm'], 'start_fam_thread':True}, keyfile=setup['key'], certfile=setup['cert'], ca=setup['ca'], ) except Bcfg2.Server.Core.CoreInitError, msg: logger.error("Core load failed because %s" % msg) except KeyboardInterrupt: sys.exit(1) If any other exceptions could occur, they should also be caught and reported appropriately. |