Is the "create user" command supported in a distributed setup (version 2.2.2)? Any time I use it, I get a distributed operation exception (screenshot: https://www.dropbox.com/s/nd9m52i8dbk7r4t/Screenshot%202016-06-15%2010.51.13.png?dl=0)
It seems that the entry is created in both servers, just with a different password hash which collides. Screenshot of user creation process (redacted) https://www.dropbox.com/s/r4oywkc5gqj6lsj/Screenshot%202016-06-15%2012.26.04.png?dl=0 and https://www.dropbox.com/s/2poi06z9mxxqr26/Screenshot%202016-06-15%2012.26.43.png?dl=0
Strangely, if I run the command on devgro1, I can login using the credentials on the OTHER server (devgro2), but not on the server I ran the command on.
To add to the confusion, I can't use the old method of inserting into OUser either: https://www.dropbox.com/s/ruxes4vkop4kigb/Screenshot%202016-06-15%2012.19.30.png?dl=0
Appears to be a bug in version 2.2.2. Recommended action is to revert to the 2.1.x versions that doesn't have this bug, or upgrade to one where it is fixed (not available as of the time of this post, but might be for an future readers).
Related
I moved a mongoDB from one atlas cluster to a different account/different cluster.
To do this I did a dump from the source db and a restore to the new account's cluster.
I did NOT have a problem restoring the db - that went fine - I can visually confirm that the hashes in the new db ARE the same as the old.
When I try to login to my app (pointed to the source) I get in fine, when I change my db setting and point to the new db I get a log in failed.
The api code is the same - running locally, the only thing that is different is the connection string.
I am using bcrypt to hash the passwords - but because the api is sitting on my local machine, that kind of takes any application layer variable out of my problem list.
With the exception of the connection string - I was using the 3.1 driver connection string to connect to the 'old' version, and I decided to try the 3.6 driver version to connect to the 'new'.
Can someone confirm that moving a db from one cluster to another, using the dump and restore method SHOULD not effect hashed password matching.??
And maybe offer suggestions on where to look for answers?
so the only difference on the code is this:
// Old
DB_URI=mongodb://u***:p***#dev0-shard-00-00-1xxx.mongodb.net:27017,dev0-shard-00-01-1xxx.mongodb.net:27017,dev0-shard-00-02-1xxx.mongodb.net:27017/db?ssl=true&replicaSet=Dev0-shard-0&authSource=admin
// new
DB_URI=mongodb+srv://n***:h***#prod-xxx.mongodb.net/test?retryWrites=true
Ok, So I finally got around to playing with stuff, and since the URI was the only change, I switched back to the 3.4 driver syntax (that long ungodly string), and it works fine.
For the record, all my "open" (non-authenticated) API calls, such as with signup, or requesting a forgotten password. and a slew of drop down lookup, all processed thru the api with the 3.6 driver, I also signed up and logged in fine - the only issue is logging in with an account that was created in the previous cluster, with the new driver connection string.
And as confirmation - now that I switched the connection string back to 3.4 - I cannot log into the account I created with the 3.6 connection string.
I'm relatively new to chef and am in the process of using the edelight mongodb cookbook. I've got the process of actually creating a standalong mongodb instance working fine. It's understanding how to use the subsequent user_management recipe to create the initial admin user and regular users.
When I add "default['mongodb']['config']['auth'] = true" to the attributes/default.rb file, and run the mongodb::default recipe, the db is created and authentication is on.
However when I run the mongodb::user_management recipe I get this error every time. Clearly I'm doing something wrong, but being new to editing chef/ruby files I can't determine what's failing. Looks like I might need to work within the users.rb attribute file?
===================================================
Error executing action add on resource 'mongodb_user[admin]'
NameError
uninitialized constant Mongo::MongoClient
The edelight cookbook has been unmaintained for quite some time now. Chef-Brigade is attempting to take over maintenance on the cookbook until a new owner can be found.
https://github.com/chef-brigade/mongodb-cookbook
There is work being implemented to fix some of the user_management issues. I am not 100% sure the current state of the user_management fixes but you would likely be better off starting with that cookbook and reporting any issues to the team there so they can work to resolve. There is active development taking place.
I would be glad to help you debug the issue if it persists on the chef-brigade flavor of the cookbook as we can actively make changes to resolve any issues.
OrientDB Studio looked to be a promising tool to explore the product for use as an object store replacement for db4o, but I unfortunately I have not been able to get to first base with it.
I am running OSX 10.6.8. The behavior described below was observed with both the 1.7.10 Mac and the 1.7.9 "all platforms" binaries:
1) I am not able to create a database with Studio. I edited the root password and restarted the server but any attempt to create a new database using Studio yields the same result: 401 Unauthorized.
And there is not much information in the logs:
2014-11-20 12:12:32:420 CONF Remote client connected from: OClientConnection [id=1, source=?, since=1416503552420] [OClientConnectionManager]
2014-11-20 12:12:32:431 FINE [ONetworkProtocolHttpAbstract.execute] Requested: POST /database/invoices/local/document [ONetworkProtocolHttpDb]
2014-11-20 12:12:32:438 FINE Disconnecting connection with id=1 [OClientConnectionManager]
2014-11-20 12:12:32:438 FINE Disconnected connection with id=1, no other active channels found [OClientConnectionManager]
2014-11-20 12:12:32:438 FINE Connection shutdowned [ONetworkProtocolHttpDb]
I had to resort to creating the new database using the console. Having to resort to using the console steepens the learning curve and is a barrier to adoption.
2) I would like to use Studio to create indexes and explore index behavior, but I do not seem to be able to open any database, even the demo GratefulDeadConcerts, as writer or admin.
Studio displays the mode (reader) at the top right of the page, and I have to believe I have no write privileges because I am not able to create any indexes on my new object database.
Any help would be Gratefully (pun intended) appreciated.
The problem is apparently not with either OrientDB or Studio.
1) I continued to test with OSX 1.7.10. Logging in as admin/admin, I noticed that Safari would open the databases as (admin) but Firefox would open the databases as (reader). After upgrading to Firefox 33.1.1 the mode now shows as (admin) and I am now able to create databases using Studio.
I just deleted localhost cookies in Safari 5.1.10 and was able to create a database using that browser as well. It's possible that step may required after changing the root password and restarting the server.
2) My problem with index creation was due to lack of understanding of how indexes work. Indexes can only be created on objects with schema-defined properties.
After opening the database and requesting schema generation using the API, Studio displayed class properties and I was able to create indexes on those properties in Studio.
db2 = new OObjectDatabaseTx("remote:localhost/invoices").open("admin", "admin");
// Tell OrientDB to automatically generate schema during class registration, this saves us some code.
db2.setAutomaticSchemaGeneration(true);
// Now register our classes...
db.getEntityManager().registerEntityClasses("your.entity.package.goes.here");
// Save the schema of our new database...
db2.getMetadata().getSchema().save();
After upgrade our IBM System i (aka i5/OS or AS/400) from V5R4 to V7R1, one of our applications that connect to DB2 using ODBC fails with the following error:
Error Code: 69899
SQLSTATE: S1000
[IBM] [System i Access ODBC Driver] [DB2 for i5/OS] PWS0005
Error occurred in the database host server code.
The symptoms are:
In a While / Wend loop a CURSOR is declared, then opens, do fetch(s) and close.
If at any iteration the cursor does not retrieve any rows, in the following iteration the error occurs after declaring the cursor (with a different SQL query) when you try to open it.
First we updated the ODBC driver to the latest version available, but the problem persists.
Because we needed an urgent solution, I solved the problem by making a pre-select to determine if the cursor will return rows, otherwise skip that iteration, this solves the problem for now but does not seem a very elegant solution.
Any idea how to get more information about the error that occurs on the host?
Thank you very much in advance.
Generally speaking, if an error occurs in the server side code, you should call IBM support and report it. They'll ask if you're on the latest cume and probably the latest database group PTFs.
The server runs the ODBC connexion in a job called QZDASOINIT. Since there are probably many connexions to the system, there are probably many QZDASOINIT jobs. To find yours, go to a terminal session and WRKOBJLCK MYPROFILE *USRPRF. You'll be presented with a list of jobs running with your user profile. At least one of them will be the QZDASOINIT job you're looking for. Use option 5 to look at the job, then option 10 to see the job log. Press F10 to see the detailed messages and F18 to go to the bottom (most recent) entries.
If the error was so severe that the server job terminated abnormally, there won't be a lock on your user profile. Instead, go to the spooled job log by using WRKSPLF.
IBM have been logging some SQL internal errors since V5R4. select * from qrecovery.qsq901s; to see any SQLCODE -901 errors.
Make sure that you have installed the latest fix pack for the latest version of System I Access
I've had this error before and it was caused by a syntax error in the connection string. It was a setting that was insignificant in older versions of the OS and more significant in newer versions, but did not cause the connection itself to fail so it was hard to track down.
For example: Port Number:8471 had a spelling mistake and was Porte Number:8471 hard to spot but once found, it fixed the problem for me. Basically everything past this part of the connection got ignored.
Wanted to add another solution to this problem. The SQL Packages that exist on your system get corrupted after/and or during upgrades. You MUST delete these packages after an upgrade. This will get rid of the old packages and will allow the system to recreate the packages at the new OS version level. When deleting SQL packages some connections/jobs may have locks on those packages so you might have to shut host services down. Use the DLTSQLPKG command to do the delete. In v7r2 and higher there are some additional steps to do as IBM changed somethings when it comes to packages you can find the info here http://www-01.ibm.com/support/docview.wss?uid=nas8N1015556
Or tell your ODBC/JDBC/.Net Data adapter/provider to not use packages. This is probably less desirable as there are performance benefits to packages.
I'm in the process of developing a deployment system for a new web app and I'm wondering where the best point in the process to manage database migrations is (the question of how to do the migrations is another problem entirely).
It seems there are two ways to go:
Use a migration script that can
either be run manually from command
line or as part of the automatic
deployment/build process
Run the migrations when the app
starts up (I'm using ASP.NET so this
can be done easily enough without
causing a long-running user request)
Does anyone have any suggestions/insight/experience with these approaches? Any other suggestions?
I can see why #1 might be more attractive - it gives me complete control over when the DB is updated. However, I quite like #2 as it allows me to quickly iterate between deployments and reduces the manual process. #2 could also be used on my development machine to allow even quicker iterations. Hmm, starting to think having both might be a good thing...
We have a sales-force system with ~100 client and we are updating database at application startup (True, our is a desktop application.) I like this approach, it's safe and iterative if we have indeterministic startpoint (is the client database new or only updated to verison x.y.z?).
But at serverside I'm preferr your #1 option: we create a SQL query file on our virtual machine (based on the copy of the original database) and runs this query against the real server.
So IMHO:
Disconnected clients: startup, iterative scripts
Server: query created on VM based on the actual and real database
So I'm interrested in this problem too, and find some (half)frameworks as RikMigrations. After some googling there is a good startplace about DB versioning/migration frameworks: .NET Database Migration Tool Roundup. Not neccessarely the documentation but the team blogs can be interresting.
I like option #1 better as it seems much more flexible. In lieu of actually performing migrations on each app start, I think I would verify that the database schema (version number?) matches the code, and if not, throw a warning or error about a mismatched database schema.
I'd prefer option #1 for a number of reasons. First, integration tests usually require your DB schema to be up-to-date, and launching a web-site to upgrade the schema will be a huge timewaster. Second, you cannot change database schema while your site is running (say, add a couple of indexes to speed things up).
As for production side of things, upgrading your database in transaction MSI-style installation is much better than attempting to upgrade at each app startup since you can potentially end up with desynchronized database-application versions.
And if you're looking for the migration framework, take a look at Wizardby.
If the application ever has to run on a customer's machine than migrating at startup can prevent a lot of support calls - assuming you can do seamless migration without user intervention (I hope you aren't normally running your web app with permission to modify the database).
If the application always runs under your control automatic migration is less of an issue - but still can be a good feature, especially if you want to minimize downtime and manual deployment steps.