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
Related
I have a uCommerce package installed for my sitecore. The problem exists when you start editing template items under sitecore/templates/User Defined/uCommerce definitions/. When you restart IIS or recycle application pool (apparently this happens after solution rebuild) the template items reset their values to the fixed one. What could be causing the problem? Is there any cache mechanism which could be causing this?
update: have checked the sitecore database, the field values are being saved and stored in database properly after iis reset/pool recycly, so there is pretty much confidence that it has to do something with caching
The UCommerce DataProvider (UCommerce.Sitecore.SitecoreDataProvider.DataProviderMasterDatabase) automatically adds the templates under sitecore/templates/User Defined/uCommerce definitions at start up so they will always be reset after each recycle.
First off, make sure that you are making your changes in the Master database and not the Web database. If that is not the issue, then try the following while logged into Sitecore as an administrator:
Go to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the Sitecore cache
Go to the Master database's content editor and look at your templates
Make any changes necessary, save and publish
Do your IIS restart / application pool recycle (the latter occurs on every build)
Go back to http://yourdomain.com/sitecore/admin/cache.aspx
Clear the cache again (just a base-case)
Go back to the Master database's content editor and look at your templates again
If the issue occurs after trying those steps, then you should open a Sitecore support ticket and see what they say. You may also want to try making a clean install of Sitecore and trying to reproduce the issue there (Sitecore Support is likely to do this as well).
The problem was that the standard values template presentation layout I have been updating was the english version. However, there was another language version set and the layout for that version was different. When uCommerce is resetting the template on application pool recycle it doesn't take into the account the multilanguage support, so the last retrieved language version of that fieldvalue is used as reset template and that different language version with different layout was used. A partial workaround is to use the same layout for all the language versions.
I have a JSF 2 project and am using Eclipse Inigo as IDE, and deploying to Tomcat 6 (which is running in a a virtual machine in VirtualBox to mimic the target environment). I am not using Eclipse to deploy. Right now I'm simply exporting a .war file and deploying it from the Tomcat manager screen. I am using HSQLDB to store users, passwords, and user roles. One project requirement that is causing me confusion is that my web app must be fully self-contained. That is to say, I deliver a .war file and they plug it in without additional configuration to Tomcat.
I've read a ton on configuring my project for form authentication, including: SO question 1, SO question 2, SO question 3, Tomcat Realm config, Java EE 6 security, and more. Those sources really helped understand how to configure my project. I thought I was almost there. However, when I deploy the web app and try to access a restricted page I always get the login error page. I attempt login with one of various users in the DB with the role required, and I think the DB is set up according to the Tomcat Documentation.
All the tutorials I've read differ from my situation in one way or another:
Uses Glassfish instead of Tomcat
Uses BASIC authentication instead of FORM
Stores users, passwords, and roles in tomcat-users.xml instead of relational DB tables
Declares roles in server.xml instead of somewhere within the .war file.
Point 4 especially is preventing me from getting a full understanding of what is and is not possible (out of the box).
I will edit this question later to post code (web.xml, etc.), but first I wanted to ask a question similar to the one in the 'SO question 2' (above), in which the OP asks whether it's possible to do form authentication without defining something in the application server. In one of the answers it sort of sounds like it is not possible, but it's not quite definitive.
So, is it possible to implement form authentication without modifying files in the server (specifically server.xml and tomcat-users.xml as so many tutorials show)? Can form authentication with a DataSourceRealm be done with the requirement of the .war being fully self contained? If so, how? Can I include additional .xml files in my .war that would do the trick? Can I include everthing I need in web.xml and context.xml?
I've tried including everything in web.xml and context.xml, but it is not working. I thought I had things configured properly except for not having anything in the server.xml file.
I'll leave it at that for now. If what I need is possible, I'll edit with code to try to figure out what I'm doing wrong, otherwise, I'll save the trouble. Also, if what I need is not possible using form authentication, can anyone recommend a good alternative to achieve the same in a self-contained .war? (I'm throwing around the term 'self-contained .war' for lack of a better way to describe it...if there's a better or more precise term, let me know.)
Unfortunately, you can not do it.
Realms are configured in the server.xml file so if you want to authenticate a user against database you have to configure it in the server.xml file.
If you want to authenticate a user against database and ensure all your configuration will be within your WAR file please consider to use the Spring Security framework: http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html
It is the great and simple framework that solves a lot of authentication / authorization problems.
I need to make an upgrade of Liferay, as mentioned above(5.2->6.0) So far, as my research (1,2,3) shows I need to:
Make backups of the Database and file system of plugins (especially portal*.properties).
Overwrite dependency jars
Deploy new .war
Set permission algorithm to 5 in the properties (as L-5.2 uses it, however L-6.0 uses 6)
Start application,
see if the DB updates correctly
see if the portal is working correctly
Clean up user-specific permissions
Convert legacy permission algorithm to 6 in the control Panel
Migrate a custom theme.
Upgrade EXT to EXT Plugin(p. 398)
It's fairly understandable, but I stumbled upon this thread(Missing FileEntryForm class). Are there any more changes of this kind?
Also, is there something else I'm missing?
Thanks :)
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.
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.