I'm using a local machine for development that needs to allow Admin Party (everyone is an admin). When I first installed CouchBase Single Server, it was working, but I created a user and that turned Admin Party off. I've re-installed multiple times. Killed off everything I can find associated with couchbase, but every re-install retains the Admin Party off configuration, and remnants of my old database(s).
For reference:
Host: OS X 10.7.2
CouchBase Single Server Binary (not installed from source)
CouchBase SS Version: 1.2
I've tried blowing away the following:
/Applications/Couchbase\ Single\ Server.app/*
~/Library/Application\ Support/CouchbaseServer/*
but things must still be being stored elsewhere. lsof doesn't yield anything except for files in those locations and this:
/private/var/db/dyld/dyld_shared_cache_x86_64
Thanks!
UPDATE
Fixed this on my own. After more find/grepping for [Cc]ouch, i found the following files:
/Users/redacted/Library/Caches/com.couchbase.couchbase-server
/Users/redacted/Library/Caches/com.couchbase.couchbase-server/Cache.db
/Users/redacted/Library/Logs/Couchbase.log
/Users/redacted/Library/Logs/Couchbase.log.old
/Users/redacted/Library/Preferences/com.couchbase.couchbase-server.plist
/Users/redacted/Library/Preferences/com.couchbase.couchbase-server.plist.lockfile
/Users/redacted/Library/Preferences/couchbase-server.ini
/usr/local/Library/Formula/couchdb-lucene.rb
/usr/local/Library/Formula/couchdb.rb
Because I'm re-installing couch anyway, there is no reason for me to keep anything couch related. I blew all of these away, reinstalled and Admin Party was re-enabled. Somehow it still has record of my old DB names, but at least admin part is back in action.
Found a solution other than re-installing the server:
Remove (or move) ~/Library/Preferences/couchbase-server.ini
Then, finally, my Admin Party came back!
Search inside your CouchDB configuration files (local.ini, default.ini, local.d/*, ... usually under /etc/couchdb or similar) for the [admins] section and comment out all the users defined there (use ; character).
Restart your CouchDB server and you'll be back in Admin Party mode.
Related
Xcode 9 introduces a new version of the Xcode Server (no longer bundled with with Server.app). The backing couchdb instance for Xcode Server can be accessed through
http://localhost:10355/_utils
In previous versions you were able to examine the documents and even modify if needed. (For instance, I previously did this to artificially inflate an integration number when setting up a bot on a different server. I use the $(XCS_INTEGRATION_NUMBER) variable for my build numbers.)
Now, the database requires credentials. I know you can find the password in
/Library/Developer/XcodeServer/SharedSecrets/XCSDCouchDBSecret
But does anyone know the username?
After more investigation I found my answer...
/Library/Developer/XcodeServer/Configuration/xcscouch.ini
This file contains the basic CouchDB configuration for the Xcode Server. Under the [admins] section is a username=password list.
The default username for the Xcode Server CouchDB instance is xcscouchadmin
Our current deploy process goes something like this:
Use grunt to create production assets.
Create a datestamp and point files at our CDN (eg /scripts/20140324142354/app.min.js).
Sidenote: I've heard this process called "versioning" before but I'm not sure if it's the proper term.
Commit build to github.
Run git pull on the web servers to retrieve the new code from github.
This is a node.js site and we are using forever -w to watch for file changes and update the site accordingly.
We have a route setup in our app to serve the latest version of the app via /scripts/*/app.min.js.
The reason we version like this is because our CDN is set to cache JavaScript files indefinitely and this purposely creates a cache miss so that the code is updated on the CDN (and also in our users' browsers).
This works fine most of the time. But where it breaks down is if one of the servers lags a bit in checking out the new code.
Sometimes a client hits the page while a deploy is in progress and tries to retrieve the new JavaScript code from the CDN. The CDN tries to retrieve it but hits a server that isn't finished checking out the new code yet and caches an old or partially downloaded file causing all sorts of problems.
This problem is exacerbated by the fact that our CDN has many edge locations and so the problem isn't always immediately visible to us from our office. Some edge locations may have pulled down old/bad code while others may have pulled down new/good code.
Is there a better way to do these deployments that will avoid this issue?
As a general rule of thumb:
Don't do live upgrades. (unless the language supports it, but even then think twice)
Pulling code using git pull and then waiting for the app to notice changes to files sounds a lot like the 90's: uploading php files to an apache web server using ftp (or sftp if you are cool) and waiting for apache to notice that they were updated. It can't happen atomically, so of course there is a race condition. Some users WILL get a half built and broken site.
I recommend only upgrading your live and running application while no one is using it. Hopefully you have a pool of servers behind a load balancer of some sort, which will allow you to remove them one at a time and upgrade them.
This will mean that users will be able to use both the old and the new site at the same time depending on how and when they access it, but that is much better then not being able to access it at all.
Ideally you would be able to spin up copies of each of the web servers that you have running with the new version of the site. Check that the new version does work, and then atomically update the load balancer so that everyone gets bumped to the new site at the same time. And only once everything is verified to be working perfectly the old machines are shut down and decommissioned, or reused.
step 4 in your procedure should be:
git archive --remote $yourgithubrepo --prefix=$timestamp/ | tar -xf -
stop-server
ln -sf $timestamp current
start-server
your server would use the current directory (well, a symlink) at all times. no matter how long the deploy takes, your application is in a consistent state.
I'll go ahead and post our far-from-ideal monkey-patch that we're using right now.
We deploy once which may or may not go as planned, once we're sure the code is deployed on all the servers we do another build where the only thing that changes is the version number.
Then we deploy again server by server.
The race condition still exists but because the application code between the two versions is the same this masks the issue since no matter which server the CDN hits it gets the "latest" code.
I've been following along with the actual MongoDB docs here
as well as several tutorial articles that are getting me absolutely nowhere.
Running a 64bit windows OS (which is a work computer, and my particular windows login is not an administrator login.. so I make sure to open any exe files as administrator). I can't do anything in the terminal beyond "mongo" or "use [db name]".
I cannot save or add anything like db.testData.insert( j ). Even typing "show dbs", I get an error that says
listDatabases failed:{ "ok" :0, "errmsg" : "unauthorized" } at src/mongo/shell/mongo.js:46
With every example I've followed, I can never seem to be "authenticated" to get past point A. Please help me! I have no idea what I'm doing wrong at this point.
UPDATE:
Sorry for the confusion, everyone. The problem turned out to be that I had an old MongoDB service still running in the background that I needed to disable.
The service must have been turned on while I was testing out some node packages or something. Once I disabled the service, everything started working as expected.
So for those of you who are having trouble, make sure you open up services.msc and make sure nothing is running MongoDB
As there isn't a formal installer for Windows, I'd recommend you delete the data folder and restart. Out of the box, there is no security in MongoDb, so you've followed a step which later requires a password. Either retrace your steps, or start over.
You don't need to switch to the admin Database. I'd suggest you instead switch to a test database for example:
> use test
switched to db test
By default, without extra configuration, on Windows you can delete the contents of c:\data\db when MongoDb isn't running (but if you're using a configuration file that specifies the dbpath, delete the contents of that folder).
There are a number of tutorials with details of how to configure users/security with Mongodb that you may want to read after you've resolved this issue.
There's little reason to create users and administrative control with MongoDB until you gain some experience with the platform. In fact, I wouldn't recommend it at all. It just gets in the way as you're seeing for no real gain.
I have a small solution that is composed out of 2 main projects a Mvc4 Web Api and a silverlight 5 Application. I've configured and deploy the application initially on the Azure platform and it all went great, but ever since when I deploy again the silverlight project does not get pushed and the online site has the old version.
I should mention all works great with the azure simulator on my local dev machine.
Anybody had a similar issue?
Regards,
I would suspect first (as Simon suggests) that the browser likely still has the previous client cached and loads that instead of downloading your new client.
You can use the version number in the code on your page that hosts the silverlight app to help. While it's easy for you to clear the cache - you don't really want to have to tell users to do that whenever you update.
Set the version to whatever your latest assembly version is (silverlight client project assembly), this will force the browser to download the client if the cached version is a lower number.
<param name="source" value="AppPath/App.xap?version=2.0.0.6"/>
Ok,
So after pulling my hair out, I finally figured out.
I have to change the build configuration to release in VS do a rebuild and then do publish because apparently the azure project does not do rebuild on the project when you publish it.
To solve this issue you'll need to identify the source of the problem (is it a client side problem where you have a caching issue or not). Even though you say caching isn't the problem we'll need to be sure about this first.
What I suggest is that you do the following first:
Activate Remote Desktop on your role
Connect through RDP and save this file to the role: http://support.microsoft.com/kb/841290 (fciv.exe)
Find the *.xap file (usually in E:\sitesroot) and get its checksum (using fciv.exe)
Modify the Silverlight project locally (maybe change a label or move around an element) to make sure its hash has changed.
Redeploy the application
Connect through RDP and use fciv.exe to get the checksum of the *.xap file once again
Compare both checksums
If the checksums are different, then it means that the deployment worked correctly and the Silverlight xap has been updated. If the checksum is the same, the problem lies with the deployment.
Please let us know the result so we can help you find the solution.
After you have installed SharePoint you need to run the configuration wizard which typically asks what your Database server is what DB Name to use, what port to use for Central Admin, etc. Then it goes through its 1-9 install process...
Our problem is on one of our servers, which has a clean database, clean 12 hive, and no answer file is to be found (nor should it), the Configuration Wizard goes straight through to the 1-10 install process. It doesn't ask any questions at all...
Why would this occur?
This behavior is expected if your server is already attached to a farm. Was the machine previously part of a SharePoint farm and removed via the farm's Central Admin? Was a clean SharePoint uninstall/reinstall performed?