| |
| |
| |
|
Page: 1 2
Comments:
<0> anyone here using openldap with bdb backend/
<0> ?
<0> trying to get some options in DB_CONFIG to be picked up
<0> used db_recover -h /var/openldap-data yesterday, and it picked up changes, but after i rebooted box, seemed to rever back
<0> specifically im trying to seperate the logs from the bdb files for better performance
<1> where did you configure the logs to go?
<1> and have you checked to see that the DB_CONFIG file is still the same as before?
<0> set_lg_dir /opt/openldap-data
<0> ya, the file is hte same as when i last edited
<0> so i have the bdb going to /var/openldap-data
<0> and then the logs should go to /opt/openldap-data
<0> so do i need to do something besides db_recover -h /var/openldap-data to read in the configs from DB_CONFIG ?
<1> no
<1> the BerkeleyDB library always reads the file
<0> # Note: most DB_CONFIG settings will take effect only upon rebuilding
<0> # the DB environment.
<1> yes, db_recover forces the environment to be rebuilt.
<0> thats what the example file read
<0> wondering why its not picking up that log dir
<1> how do you know it's not?
<0> i have the opt/openldap-data dir chowned as ldap:ldap
<1> what version of BerkeleyDB ?
<0> Berkeley DB 4.5.20
<0> i know its not because hte logs are still being written to /var/openldap-data
<1> I've never seen it ignore a setting like that...
<0> ya, i thought it was weird too
<1> no reason why rebooting should affect it, unless your /opt isn't mounted by the time slapd starts.
<0> na, i start slapd manually right now
<0> still in testing phases
<2> hi there
<1> howdy
<0> just ran db_recover again, and now its logging right
<0> this is so damn strange :\
<1> next time you reboot, start it manually with -d -1 and save stderr to a file.
<0> -rw-r----- 1 root root 10M Feb 2 17:30 log.0000000001
<1> most likely the BDB library will log a message if there was a problem with the setting you used.
<0> that seems rather odd too..why wouldnt it be writing as ldap user
<1> how did you start slapd?
<0> $SLAPD_DIR/slapd $DEBUG -l daemon -u ldap -h "ldap:/// ldaps:///"
<1> definitely strange. you're sure you don't have any other scripts operating on the DB directory before slapd runs?
<0> ya
<0> fresh solaris install
<0> just dumped the package and configs down
<0> and then /etc/init.d/slapd start
<1> yes,but what else does that /etc/init.d/slapd script do?
<0> thats weird, it logged that one log file in the correct dir, and then all other logs now go to /var/openldap-data again
<0> 'start')
<0> if [ -f $ETC_OPENLDAP_DIR/slapd.conf -a -f $SLAPD_DIR/slapd ]; then
<0> echo 'OpenLDAP slapd service starting.'
<0> $SLAPD_DIR/slapd $DEBUG -l daemon -u ldap -h "ldap:/// ldaps:///"
<0> fi
<0> thats all it does
<1> that's the whole script?
<0> i'll paste to pastebin.ca
<0> http://pastebin.ca/337623
<0> but yes, only 3 functions...stop, start, restart
<0> and the rest of the script is variables
<1> hm
<1> pretty weird
<1> but like I said - collect some debug output
<1> possibly you've hit a bug in BerkeleyDB, but that seems unlikely. I've been running 4.5.20 for a long time, with an alternate log directory. it just works.
<0> weird
<0> keyword <moduleload> ignored
<0> looking through debug logs now
<0> line 30 (moduleload back_bdb.la)
<0> /usr/local/etc/openldap/slapd.conf: line 30: keyword <moduleload> ignored
<0> :(
<0> i dont see that file on my buildbox or the consumer server
<0> is the module compiled in?
<1> how would we know? who built your slapd? what options did they use for configure?
<0> well, i didnt use --enable-modules
<0> so im ***uming by default they are compiled in
<0> CFLAGS="-D_AVL_H" CC=/usr/local/bin/gcc LD_RUN_PATH="/usr/local/db/4/libs /usr/local/lib" LDFLAGS="-L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/db/4/lib" CPPFLAGS="-I/usr/local/include -I/usr/sfw/include -I/usr/sfw/include -I/usr/local/ssl/include -I/usr/local/db/4/include" ./configure --enable-dynamic --with-tls --enable-crypt --disable-slurpd --enable-ldbm --enable-bdb=yes --prefix=/usr/local/openldap --localstatedir=/var --with-berkeley-db
<0> recompiling now with --enable-modules
<1> why?
<1> what difference does it make, since you didn't use it before?
<1> how did you choose the configure options you used before? why did you enable ldbm?
<0> well, this is an initial install
<0> enabled ldbm because may use it, dont know yet
<1> have you ever even looked at the output from "configure --help" ? do you understand what each of those options means?
<0> but initially wanted to give bdb a shot
<0> yes, i did look at that
<0> and --enable-modules doesnt seem to be default
<0> and for whatever reason moduleload back_bdb.la doesnt seem to be working
<0> ***uming because modules dont exist
<1> never use ldbm. it is disabled by default for a reason, and the code has been deleted, it will not be in any future releases.
<1> the fact that moduleload doesn't do anything doesn't mean anything.
<1> if the backend was compiled statically there's nothing to load.
<0> ok
<1> think.
<0> so if its compiled statically, then i can take those loadmodule options out
<1> use your brain. understand what the options mean before you go changing them at random.
<0> well, i dont see any other errors in the debug logs
<0> so not really sure how else to debug this issue
<1> that wasn't an error message. it said "ignored" - it was just an informational message.
<1> now that it's started up, where are the logfiles going, and what is the ownership on them?
<1> and what are the permissions on the log directory?
<0> they are going to /var/openldap-data
<0> owned by ldap:ldap
<1> stop the server, do another db_recover, then start again with debug messages enabled
<1> actually, after the db_recover, delete all of the log files too
<0> shmget: key: 7: unable to create shared system memory region: Invalid argument
<1> sounds like your machine is hosed.
<0> ?
<1> were you using shared memory regions before?
<0> yes
<1> at what step did that error message show up?
<0> this didnt happen until i db_recover and them removed logs
<0> and then tried to start back up
<1> try the "ipcs" command
<1> why are you using shared memory regions anyway?
<0> running solaris
<1> yes, and?
<0> was following how-to from stanford
<1> that statement in itself doesn't answer "why". do you understand why the advice in that how-to is there?
<0> no
<0> ***uming to speed up performance
<1> so that how-to could have said "first sacrifice a chicken to the rising sun" and you'd follow it, without asking why?
<0> well, no
<1> ok, enough of that. yes, using shared memory performs better on solaris. but if you don't understand solaris system administration, you probably need to study up on that before you go using it.
<1> in the meantime, if it worked before and it doesn't work now, that implies that there was garbage left over in the system from the previous run.
<1> there shouldn't be; db_recover will cleanup and destroy all the shared memory regions that were allocated.
<1> the ipcs command should show you what shared memory regions are still active in the system.
<1> one of them would have a key "7" since that's the key you configured.
<1> but really, none of them should show up with the key 7 now, because db_recover should have removed those already.
<1> what does ipcs show you?
<0> dont see hte ipcs command on this machine
<0> looking for it now
<1> pastebin it when you find it.
<1> /sbin or /usr/sbin
<0> doesnt exist
<0> thinking the package isnt installed
<1> hm, the Solaris manpage says /usr/bin/ipcs or /usr/xpg4/bin/ipcs
<1> SUNWipc or SUNWipcx
<0> ya, it was SUNWipc
<0> http://www.pastebin.ca/337763
<1> looks like somehow it didn't delete everything it should have
<1> do an ipcrim -m 0
<1> ipcrm
<0> ok
<1> and ipcrm -m 1
<0> nothing
<1> to get rid of those last two pieces
<1> and read up on the ipcrm command too
<0> ok, its started back up
<1> what's in the debug log this time?
<1> how many BDB log files are there?
<0> mmap: Not enough space
<1> heh.
<1> how much free space is in your /opt/openldap partition?
<0> 133g free
Return to
#ldap
or
Go to some related
logs:
#fedora
using hypervisor boot
Libdvdcss x86_64.rpm Suse
#lisp
#php
#web
+javascript +force redraw
#perl
sane cannoscan lide 35
unrar executable for ubuntu
|
|