I am trying to back up the config and database files from an existing LDAP server to move it to a different freshly installed server (Ubuntu 18.04). I followed the steps given here: https://tylersguides.com/articles/backup-restore-openldap/ to use slapcat to create both config and data ldif files.
When I execute slapadd on the server side,
slapadd -n 0 -F /etc/openldap/slapd.d -l /backups/config.ldif works fine, but executing
slapadd -n 1 -F /etc/openldap/slapd.d -l /backups/data.ldif gives the following error:
Database number selected via -n is out of range
Must be in the range 0 to 0 (the number of configured databases)
All the sites I have been able to find regarding this migration process follow steps similar to the ones above, but none of them mention anything about preconfiguring the number of databases or anything like that. I'm not sure how to proceed from here.
almost sure that you did a mistake during dump and the content of the second file is the same as the config file
Try removing -F /etc/openldap/slapd.d from the second slapadd.
Related
I am trying to run mongodb-community#4.2 service using brew services start mongodb-community#4.2 (facing similar error, while running httpd service or any other service)
Following is the error:
Error: Failure while executing; /bin/launchctl bootstrap gui/502 /Users/chiragsingla/Library/LaunchAgents/homebrew.mxcl.mongodb-community#4.2.plist exited with 5.
There can be multiple reasons behind this error message. So, the first thing to do is to find where your mongo related logs are stored. To do that, run the following command -
sudo find / -name mongod.conf
This will get you the mongo db config file. On running this command, I got /usr/local/etc/mongod.conf. You may find it directly under /etc.
On opening mongod.conf, you will find log path mentioned there. You can open the file itself, or instead get the last 15-20 lines of this log file via tail command -
tail -n 15 <<your mongo db log path>>
Now, you will need to debug the issue mentioned in the logs. Generally, I have seen these three sets of issues -
Permission issue with /tmp/mongodb-27017.sock - While some SO answers asked to change the permissions for this file as a solution, my issue with this only went away after I removed this file.
Compatibility issue - If you see a message like Version incompatibility detected, it means that the mongodb version you have currently installed is different from the version whose data is present on your system. Uninstall the current mongodb version and then install the correct older version (if you don't want to lose the data).
Once you have done it, and your mongo is up and running, and you want to upgrade mongodb version, follow this SO answer.
Permission issues with WiredTiger - Using chmod to change file permissions resolved these.
In case you have any issue other than these three, you will still need to search more on SO and figure it out. Hope this was of some help! :)
I've been given a project to extract data from a PostgreSQL database. I've no previous experience with PostgreSQL but the project I have is to bug fix existing code, so all the logic to connect to the engine and get data is already in place.
The problem I have is the database has been given to me in the form of the folders and files straight from the source HDD, not a backup (which isn't going to happen so "Get the customer to give you a backup instead isn't an option here).
The folders also contained the actual PostgreSQL binaries so I looked a the version (9.4.14) and downloaded the nearest (9.4.18) from the PostgreSQL site and installed it. Now all I have to do is some how is to get it to look at my given data files.
I tried the obvious of copying the contents of the data folder into the installed data folder but after the PostgreSQL service won't start.
I did find a option in the conf file:
#data_directory = 'ConfigDir'
I changed this to:
data_directory = 'C:\customer\data'
But again the service won't start after this.
The data directory used by the service is defined through the service command line which overwrites any property defined in postgresql.conf.
You need to re-create the service in order to change the data directory, e.g.:
Remove the service:
pg_ctl -unregister -N postgresql-9.1
postgresql-9.1 is the "real" name of the service, not the "Display Name". You can see that in the properties of the service inside the "services" app.
Then re-create the service with the correct data directory:
pg_ctl -register -D -D c:\customer\data -N postgresql-9.1
Another way of "debugging" startup errors in Windows, is to start Postgres from the command line (not through the service) because some errors during startup are not logged in the Postgres logfile but they are displayed on the command line. You can do that with e.g.:
pg_ctl start -D c:\customer\data`
If the bin directory is not in your PATH you need to specify the full path to it on the command line, e.g.: c:\Postgres9.1\bin\pg_ctl
I have a zillion machines in different places (home network, cloud, ...) and I use fish on each of them. The problem is that I have to synchronize their configuration every time I change something in there.
Is there a way to load the configuration from a remote repository? (= a place where it would be stored, not necessarily git but ideally I would manage them in GitHub). In such a case I would just have a one liner everywhere.
I do not care too much about startup time, loading the config each time would be acceptable
I cannot push the configuration to the machines (via Ansible for instance) - not of them are reachable from everywhere directly - but all of them can reach Internet
There are two parts to your question. Part one is not specific to fish. For systems I use on a regular basis I use Dropbox. I put my ~/.config/fish directory in a Dropbox directory and symlink to it. For machines I use infrequently, such as VMs I use for investigating problems unique to a distro, I use rsync to copy from my main desktop machine. For example,
rsync --verbose --archive --delete -L --exclude 'fishd.*' krader#macpro:.config .
Note the exclusion of the fishd.* pattern. That's part two of your question and is unique to fish. Files in your ~/.config/fish directory named with that pattern are the universal variable storage and are currently unique for each machine. We want to change that -- see https://github.com/fish-shell/fish-shell/issues/1912. The problem is that file contains the color theme variables. So to copy your color theme requires exporting those vars on one machine:
set -U | grep fish_color_
Then doing set -U on the new machine for each line of output from the preceding command. Obviously if you have other universal variables you want synced you should just do set -U and import all of them.
Disclaimer: I wouldn't choose this solution myself. Using a cloud storage client as Kurtis Rader suggested or a periodic cron job to pull changes from a git repository (+ symlinks) seems a lot easier and fail-proof.
On those systems where you can't or don't want to sync with your cloud storage, you can download the configuration file specifically, using curl for example. Some precious I/O time can be saved by utilizing HTTP cache control mechanisms. With or without cache control, you will still need to create a connection to a remote server each time (or each X times or each Y time passed) and that wastes quite some time already.
Following is a suggestion for such a fish script, to get you started:
#!/usr/bin/fish
set -l TMP_CONFIG /tmp/shared_config.fish
curl -s -o $TMP_CONFIG -D $TMP_CONFIG.headers \
-H "If-None-Match: \"$SHARED_CONFIG_ETAG\"" \
https://raw.githubusercontent.com/woj/dotfiles/master/fish/config.fish
if test -s $TMP_CONFIG
mv $TMP_CONFIG ~/.config/fish/conf.d/shared_config.fish
set -U SHARED_CONFIG_ETAG (sed -En 's/ETag: "(\w+)"/\1/p' $TMP_CONFIG.headers)
end
Notes:
Warning: Not tested nearly enough
Assumes fish v2.3 or higher.
sed behavior varies from platform to platform.
Replace woj/dotfiles/master/fish/config.fish with the repository, branch and path that apply to your case.
You can run this from a cron job, but if you insist to update the configuration file on every init, change the script to place the configuration in a path that's not already automatically loaded by fish, e.g.:
mv $TMP_CONFIG ~/.config/fish/shared_config.fish
and in your config.fish run this whole script file, followed by a
source ~/.config/fish/shared_config.fish
I tried finding solutions, but nothing helps.
I need to do a backup of my pgsql data from the app, I haven't used for months now. I have discovered, that the postgresql server is not running. But cannot start it.
I run pg_ctl -D /usr/local/pgsql/data -l logging.log -w -s start as pgsql user (su pgsql). Output says that it couldn't start a server and tells me to check logs. But logging.log is an empty file. Any default logging file I have found on the web about is modified months ago or empty or even doesn't exist.
I have no idea how to find the error, since logs are empty or I just don't know where to look for them.
Important note: it was working few months ago, but there were almost no changes in that time (possible hostname change).
Postgres is v9.1
System: FreeBSD 10.0-RC4
Some versions of FreeBSD ports installed PostgreSQL with syslog logging enabled. You can confirm this by looking at /usr/local/pgsql/data/postgresql.conf for log_destination = 'syslog'
If that is the case, the logging output should be visible in /var/log/messages
Default syslog logging enabled (log_destination = 'syslog') and logging output should be visible in /var/log/messages.
If you want to make a log in a separate file:
1) Create log file:
touch /var/log/postgresql/postgresql.log
2) Edit /etc/syslog.conf, append lines
!postgres
*.* /var/log/postgresql/postgresql.log
!*
After editing, you need to restart the service
service syslogd restart
4) do not forget to rotate postgresql.log (edit /etc/newsyslog.conf)
5) Perhaps in order to see something you will need to set the logging level. As an example, add to your postgresql.conf
client_min_messages = log
log_min_messages = info
log_checkpoints = on
log_connections = on
log_disconnections = on
I'm able to see queries in MongoDB, but I've tried to see what writes are being performed on a MongoDB database without success.
My application code doesn't have any write commands in it. Yet, when I load test my app, I'm seeing a whole bunch of writes in mongostat. I'm not sure where they're coming from.
Aside from logging writes (which I'm unable to do), are there any other methods that I can use to determine where those writes are coming from?
You have a few options that I'm aware of:
a) If you suspect that the writes are going to a particular database, you can set the profiling level to 2 to log all queries
use [database name]
db.setProfilingLevel(2)
...
// disable when done
db.setProfilingLevel(0)
b) You can start the database with various levels of versbosity using -v
-v [ --verbose ] be more verbose (include multiple times for more
verbosity e.g. -vvvvv)
c) You can use mongosniff to sniff the port
d) If you're using replication, you could also check the local.oplog.rs collection
I've tried all of jeffl's suggestions, and one of them was able to show me the writes: mongosniff. Thanks jeffl!
Here are the commands that I used to install mongosniff on my Ubuntu 10 box, in case someone else finds this useful:
git clone git://github.com/mongodb/mongo.git
cd mongo
git checkout r2.4.6
apt-get install scons libpcap-dev g++
scons mongosniff
build/linux2/normal/mongo/mongosniff --source NET lo 27017
I made a command line tool to see the logs, and also activate the profiler activity first without the need of others client tools: "mongotail".
To activate the log profiling to level 2:
mongotail databasename -l 2
Then to show the latest 10 queries:
mongotail databasename
Also you can use the tool with the -f option, to see the changes in "real time".
mongotail databasename -f
And finally, filter the result with egrep to find a particular operation, like only show writes operations:
mongotail databasename -f | egrep "(INSERT|UPDATE|REMOVE)"
See documentation and installation instructions in: https://github.com/mrsarm/mongotail