> Submission from: (NULL) (22.214.171.124)
> If I login to FAQ-O-MATIC and choose [Trash Answer] to remove spam then this
> message is generated:
> problem: Invalid header value contains a newline not followed by whitespace:
> location="Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e D... at
> (eval 6) line 34.
Strange. I only got that when I wasn't logged in yet.
> Not sure whether my login worked correctly though.
> I cannot tell from all the mess on the UI.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Submission from: (NULL) (126.96.36.199)
All these are just spam:
(Yes, I know that I have to login to edit/remove things but it does not work
(see also ITS#8468)
Also the HP-UX answer only contains broken deep links and therefore should also
Submission from: (NULL) (188.8.131.52)
If I login to FAQ-O-MATIC and choose [Trash Answer] to remove spam then this
message is generated:
problem: Invalid header value contains a newline not followed by whitespace:
location="Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e D... at
(eval 6) line 34.
Not sure whether my login worked correctly though.
I cannot tell from all the mess on the UI.
Full_Name: Jordan Potter
Submission from: (NULL) (2607:ea00:107:3c01:58d5:9d61:2a71:79f1)
I've been trying to create LMDB files for a particle physics project in
classifying particle interactions. Anyways, I modified an old code used to
create levelDB files from a TTree in the Root software developed by CERN using
c++. Then, I tried to run the neural net on the lmdb files and it gave me an
error that std::string_length was too large. And I tried to show the images I
had saved in it and it didn't show me anything, whereas on an LMDB file I had
from one of the caffe tutorials it did show me the image.
Do you have any ideas of what could be wrong? It think it is likely that I
messed something up and can't find a lot of documentation for building LMDB
files. In addition, I'm fairly new to coding and I had a hard time reading the
API page due to this. If you have any ideas of how to help that would be great.
Full_Name: Norbert MASSA
OS: CentOS 7.1
Submission from: (NULL) (184.108.40.206)
I'm struggling to find a root cause on a weird problem which recently happened
on one of our servers, let me give you some history :
- server installed beginning of April
- openldap 2.4.40 installed via packages
- client data loaded into ldap, no problem
- server had never been rebooted since
We have a script that (luckily, see why below) makes a backup every night, with
2 different commands :
- slapcat > file-slapcat.ldif
- ldapsearch -b "dc=our_root" -x -D "cn=admin,dc=our_root" -w password >
So far so good, the application behind was running fine, users were added and
authentication was successful.
That's for the background.
Now, 3 days ago during night, there was a planned reboot of the server, and
after it came back, it appeared our LDAP server was missing lots and lots of
entries that should have been here since months. Even some passwords were "back
to their values weeks ago". Weird.
So let's have a look at the backups, that's where the fun stuff begins : it
appeared that the ldapsearch backups were always complete whereas the slapcat
ones never where ! It looked like slapcat was not seeing any other data than
what was added at the beginning.
The final solution was to perform a restore / import of the ldapsearch generated
So from a system perspective, it would appear the behavior was something like :
- new data was storred in "some kind of memory"
- slapcat, as it's reading the files on the drive, would not see it :-(
-dadapsearch, as it's using ldap protocol, would see it :-)
- after the reboot => everything was lost, slapcat & ldapsearch were seeing the
same (incomplete) data.
Is it something possible ? I was unable to find anything related on google, and
sadly have no idea how to reproduce
Thanks a lot,
> Module loading is a generic task, IMO it doesn't make sense to talk
> about in the context of an individual module.
This is true.
But there should be a hint that the monitor database must be the last database
backend (order!). Otherwise it does not see all other backends.
On Fri, Jul 15, 2016 at 12:06:22AM +0000, dave(a)pandora.com wrote:
>I've attached a patch whichrovivides some minimal instructions to enable
>monitoring via cn=config
Thanks for the patch!
I commented on these points in IRC, duplicating here for the record:
Module loading is a generic task, IMO it doesn't make sense to talk
about in the context of an individual module. Covering how to load each
module would get repetitive really quickly.
Also, while the LDIF you wrote makes sense, the way of authenticating to
the config database is local to each site (the -H ldapi:// -Y EXTERNAL
in your example is to some extent a Debian-ism), so this is another
thing that I don't really think should be covered when talking about a