Is there a SELinux ruleset somewhere? I read somewhere that if someone knows
how to set up a ruleset to inform you. (I assumed 'you' means 'developers').
I know how to set up a SeLinux ruleset thing. Thing is; this is a hell of a
job... IF there is something unfinisches oid from someone i might want to
use is. I could use a list or something with things that dont work with
SELinux enabled, should i search the bugreports or so?
Please CC to my personal mail couse i'm not on the list. Thanks
I am in the process of writing a custom login module using LDAP.
I am attempting to use a cert (PKCS12 Cert) for the users "password".
I would like to load the cert from a keystore and validate it against the
LDAP entries userPKCS12 attribute.
Please can someone let me know if this is possible and then let me know how
this may be achieved.
Any assistance would be appreciated.
I have convdate on my system.
I cannot use it though!
how can I activate this command and get it running?
thank you regards,
MSc, BEng, Dipl.-Ing.
Yahoo! Autos. Looking for a sweet ride? Get pricing, reviews, & more on new and used cars.
Bug(s) fixed: 175170
Bug Description: Directory Server Admin Server Dies after Secure Bind to
Reviewed by: ???
Fix Description: This fix makes the assumption that mod_nss will always
be used. It is possible to use mod_admserv without mod_nss - this would
mean that the admin server accepts http, but uses ldaps to communicate
with the DS. However, I don't forsee that happening, so in order to
simplify things, this fix makes mod_nss resposible for initializing NSS
and shutting it down properly.
Another problem was the memory and resource leaks. pset's have to be
disposed of after use. This appears to have been a problem in the old
NES libAdmservPlugin as well since most of the code was just
copied/pasted. There were also a couple of other memory leaks.
NOTE: This is only part of the total fix, which will involve changes to
mod_nss, ldap sdk, and admin server components.
Platforms tested: FC4
Flag Day: no
Doc impact: no
I started from scratch, installing downloading, compiling and installing
everything on another machine. Here is exactly what I did:
I started from scratch on a machine with Ubuntu Linux, kernel 2.6. I
downloaded and installed OpenSSL 0.9.8. Then I download and installed
Apache 2.0.55 with SSL enabled. After that, I downloaded NSPR 4.6 (both the
source tree and the release) and NSS 3.10 (source tree). I copied the
nsprpub from the mozilla dir of the NSPR 4.6 source tree to the mozilla dir
of the NSS 3.10 source tree. After compiling NSS, I used this and the
compiled release of NSPR 4.6 to compile mod_nss, which I downloaded from the
Fedora Directory Server website.
After compiling mod_nss, I installed it and modified the nss.conf (in the
Apache conf dir) file as follows: put <IfDefine SSL> and </IfDefine> around
its contents, specified where NSS should be looking for its database and
changed the nickname of the certificate NSS should look for in the database.
At this point, I could run 'apachectl startssl', which would ask me for the
NSS database password and then start. I could establish the secure
connection through a browser - after being asked to accept the certificate
(which is the one I wanted NSS to use).
However, if I run 'httpd -X -k start' or 'httpd -X -k startssl', I get a
segmentation fault and a core dump. When I used GDB to analyze it,
everythig seems fine until at some point, when the httpd executable receives
a SIGSEGV signal for a segmentation fault.
Now, if I reinstall Apache 2.0.55 from the same source tree I used before
(after first deleting the directory of the installed Apache), I can run
'httpd -X -k start' with no problem. In the end, I generated a key and a
self-signed certificate and fired up Apache w/ mod_ssl with 'httpd -X -k
start -DSSL'. It worked alright.
So, it seems that when I try to use mod_nss, I get a segmentation fault when
I try to use debugging. When I revert back to mod_ssl, it works fine.
Where could things be going wrong?
I used ulimit as you told me and Apache dumped a core file at the next
segmentation fault. I ran this with gdb (typed 'gdb httpd <core-file>' in
the Apache 'bin' directory)
For some reason, somewhere in libpthread.so.0, Apache is invoking
../../../../mozilla/nsprpub/pr/src/pthreads/pthreads.c. This file, however,
is apparently not found, be cause I get
"../../../../mozilla/nsprpub/pr/src/pthreads/pthread.c: No such file or
directory." Similarly, it doesn't find sslsnce.c.
Now, from now on, the httpd process in GDB either exits normally, or
produces segmentation faults at different points of its execution.
I don't always get this segmentation fault almost immediately when I start
Apache. Sometimes it would produce output to the point that I starts
waiting for connections, but then when I connect to it through FF, the
browser would be waiting to receive the server_hello but it wouldn't come.
Sometimes, the TLS handshake continues even further.
In he meantime, I checked my database, it seems to be fine, even though
SSL_TRC still produces that -8174 error. I checked inside
nss_engine_init.c, NSS_Initialize() returns SECSuccess. I am not quite sure
this guarantees that the database is good.
Wow, thanks for the patch!
The trick is going to be in making this compatible with both Apache
2.0.x and 2.2.x.
I can go ahead and replace the APR_STATUS_IS_SUCCESS calls as you have
since the macro has gone away.
It looks like the big change is with the new regex structure and its
defines and the renaming of http_method to http_scheme. I guess I can do
something with AP_SERVER_*VERSION_NUMBER to work around that.
Nice catch on the -avoid-version to libtool.
I'll see if I can't get this into the tip this week.
> I haven't done tracing in mod_nss for a very long time but it did work
> early in the development of the module.
> I'm a little confused what you mean about Apache "debug" versus "normal"
> mode. Are you referring to the -X flag? I use that frequently myself.
> What problem are you trying to solve?
> I believe the error -8174 is a bad database error. This shouldn't cause
> a segfault. Are you seeing this when not doing debugging?
> Is it dropping a core file?
Yes, by the debug mode and normal mode I mean using -X as opposed to not
Yes, I see the -8174 error w/ or w/o debugging, but Apache with mod_nss was
working ok in normal mode (w/o -X) despite of the -8174 error, so I guess I
just ignored it. I'll rebuild my database I guess.
I don't find any core files in the 'bin' directory, where I run 'httpd -X -k
start -DSSL'. Should I be looking for them elsewhere?
What I am doing in essence is that I am extending the TLS/SSL3
implementation in the NSS package to incorporate an extension (as defined in
RFC3546). Then, I use this modified NSS in Firefox 1.5 and Apache 2.0.54 w/
mod_nss to test my modifications to the TLS handshake.
Inside NSS, I am using the SSL_TRC macros for debugging. It works fine with
Firefox, but I needed Apache to stay attached to the shell, so I can see the
SSL_TRC output. Alternatively, I am trying to get NSS to ouput the
debugging information to the Apache log files, but this might be more of a
hack than the right way to do it. Do you have any alternative suggestions
So, just to confirm, you are using Apache 2 with mod_nss and the -X flag and
it works OK, right?