Somewhere I did something silly.
I was deploying my Rails app via cloning the Mercurial repo down onto my Ubuntu server. It worked the first time, and then...well, I made a small change on my dev machine, pushed the changes to the repo, and then deleted the copy on the Ubuntu server and re-cloned from the repo.
The clone operation (the second, and third, and 'n' times) works without error, but I don't have write access to the files that were cloned.
When I try to startup my mongrel - it can't create the /tmp folder, and because of no write access, fails to start the Rails app.
Fixed through work around stated in comment above.
Related
I am trying to move an old Wordpress install to Openshift.
So I setup two gears, one running MySQL (Gear #1) and the other is setup to be a scalable PHP5 gear (Gear #2). I have manually restored the database data to Gear #1 and manually restored original Wordpress files in Gear #2 under ~/app-root/runtime/repo. The app is running fine now with everything in place.
However, when I try to raise the max number of scalable PHP5 gears from 1 to 2, the app stopped working and showing only the default gear landing page, just like what an empty gear would show. Setting maximum scalable gears back to 1 then the app would work again.
Is it true that the Wordpress files (or any other PHP or web files under ~/app-root/runtime/repo) must be checked in with Git in Gear #2, in order for scaling up to Gear #3+ to work properly? If so, is there anyway I can check-in the files that I already have in Gear #2 from within itself? If not, how can I check-in the set of files that I already have from the old Wordpress install?
Thank you for your help in advance!
Cheers,
KC
If you want to get the files on your web gear into git you have two options:
1.) SSH or SFTP into your gear and copy the files to your local workstation, then clone your git repo to your local machine, and copy the files into it, git commit & git push. Then your files will be deployed properly.
2.) SSH into your gear, initialize a git repo in your app-root/repo folder, and then setup your git repo in that gear (the one openshift created) as a remote and add/commit/push your files, then you can do a clone on your local workstation and a push and everything should deploy correctly.
I spoke with operations about this:
We do an rsync from the app-deployments directory, which are the files that were in git. So it does seem at this point that git must be used for scaled applications to work correctly. Please add your use case to http://openshift.com/ideas
I'm using easy mercurial. I have changed a computer, but still use same account for my repository. when I pushing things to my repository, it always failed.
The prompt said: A Mercurial command failed to run correctly. This may indicate an installation problem or some other problem with EasyMercurial.
More Detail showed: warning: code.soundsoftware.ac.uk certificate with fingerprint 74:51:c7:c4:9b:85:de:05:02:2f:9f:ec:7f:16:25:4c:68:48:74:7c not verified (check host finger prints or web.cacerts config setting)
I use windows 7 and the installation is correct. I re-installed it many times, but it always failed to push. Then I used my old computer, re-installed the Mercurial, but it also fail to push. But I can push things correctly in my old computer before I uninstalled Mercurial in it. And I didn't find solution in wiki for my problem. Could anyone help me? What should I do? That's an emergency, I need to solve this as soon as possible!
Thanks!
Based on your error message it seems that mercurial is not trusting the host you are trying to push to.
Try add this to your .hg/hgrc file in the top level of your repository (if it doesn't exist, create a file called hgrc (no extension) in the .hg directory and open it with a text editor and add this):
[hostfingerprints]
code.soundsoftware.ac.uk = 74:51:c7:c4:9b:85:de:05:02:2f:9f:ec:7f:16:25:4c:68:48:74:7c
If that works, you may want to add the same to %USERPROFILE%\Mercurial.ini if you are pushing to that server from multiple repositories.
reference: mercurial hgrc files hostfingerprints
I'm running into a problem with a user not being able to push his commits into a Mercurial repository and am perplexed as to why it's not working for him. I've tried several things to figure out what's up, Googling doesn't turn up anything helpful... so here I am.
First, the configuration. We have a Windows XP SP2 x64 machine on our network acting as our official repository server. This contains several repositories on it. We clone / push / pull using a folder on that drive that is shared. Permissions are given to everyone for read access. Users that can push (including the user that has problems), are given full control. The user's machine is Win XP based. My machine (used to help troubleshoot things) is also Win XP based.
Second, the symptoms. The user is using TortoiseHg 2.1.1 to do his work. He can clone just fine, commits to his local repo are a-o-k, etc. When he tries to push, however, TortoiseHg returns a "abort, ret 255" code. Not very helpful. So, we've gone to the command line and have issued "hg push -v --debug". Here it returns "abort: Access is Denied". This same user can write to the server's shared folder no problem -- he can create files, directories and delete the same as well. So, reading / writing access the drive / folder is not an issue.
Third, our experimentation results. Here are some weird results from testing. The user created a new, local test repo. I logged into the server machine and created a test repo for him to push to. The user checked in a file and then pushed it up to the test repo on the server machine. This worked fine. No aborts. Life was good. He was able to do a few more pushes and it continued to work as expected. I then cloned the repo to my machine, updated a file, and pushed it back out. After the user then pulled in my changes and tried to push back to the server, he once again encountered the dreaded "Access is Denied" message. Meanwhile, I can still update the project without any problems.
As another experiment, we had the user log out and another user log in. They did so and were able to push to the server repo without a problem. Original user logs back in, makes some changes, etc. and once again hits the brick wall of "Access is Denied".
As far as we can tell, the problem is not related to Windows credentials. Otherwise, we'd expect that creating arbitrary files on the server's shared folder would not work. Further, until I made an update to the test repo the user created, he could push to that particular repo just fine.
Any ideas? What additional credential checks is Mercurial making that might cause this?
UPDATE:
After a tip from Wim, I started to look at the permissions on the various objects of the repo using 'cacls'. This is a Windows tool that "displays or modifies access control lists of files". I had the user create a new repo and then took a snapshot of the permissions. I then checked in a file to the same repo and took another snapshot of the changes.
It turns out that there are several repo file permissions that get updated as a result of this: undo.bookmarks, undo.branch, undo.desc, undo.dirstate, branchheads, 00changelog.i, 00manifest.i, undo, and the single file of the repository. All of these files had permissions similar to the following:
C:\Projects\Mercurial\hgtest4\.hg\store\undo BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
DOMAINxxxx\USERIDxxxx:F
BUILTIN\Users:R
(actual DOMAINxxxx and USERIDxxxx values have been altered). Prior to my check-in, DOMAINxxxx & USERIDxxxx reflected the user's domain and userid. After my check-in, these got updated to mine (we're on the same domain, but the userid is obviously different.) I was able to check things in and out even though my userid wasn't listed because I'm a member of the BUILTIN\Administrators group. The user with the problem is not. So, I'm guessing that after I checked things in, the system no longer saw him as a credentialed user with write-access (BUILTIN\User:R indicates Read-only access) and therefore caused the access denial.
I've got a terribly Q&D fix in place right now (user is now part of the Admin group...) The real fix is going to be to get the repo off of Windows Sharing and on to a proper server configuration.
He was able to do a few more pushes and it continued to work as expected. I then cloned the repo to my machine, updated a file, and pushed it back out. After the user then pulled in my changes and tried to push back to the server, he once again encountered the dreaded "Access is Denied" message.
It sounds like your push creates or modifies files in the .hg folder in such a way that they are (or become) inaccessible for the other user.
I'm no expert on NTFS file permissions, but I think you can fix such situations by forcing all the content of the folder to inherit its permissions. Try selecting "Replace all child object permissions with inheritable permissions from this object" in the Advanced Security settings of the folder.
However, sharing the repository files directly with Windows file sharing is not recommended. You need a server process between the users and the repository files for the sake of performance, data integrity and security. Without such a gatekeeper, granting commit access also means granting the ability to destroy/corrupt the repository files (or as you found out in this case, changing their permissions).
See Publishing Mercurial Repositories on the Mercurial wiki for more information about other options.
When trying to commit on my locally cloned repository of a code repo on my network share, I was getting the same error message:
00manifest.i Access is denied
Probably overly simplistic, but removing some of the read only permissions to the offending files made my hg commit work fine.
I just had the same issue abort: Access is denied. The cause was my firewall (Privatefirewall) silently blocking some actions of hg.
I was getting exactly the same error message when trying to hg push at the windows command prompt. I'd recently received a new user profile after the old one had corrupted. I then ran into this "Access Denied" error. In TortoiseHg I received a similar message of "Aborted: Error 255".
I tried the advice given here by Wim Coenen as it seemed to fit; given my new user credentials. Eventually, I tracked the error to a badly installed Windows Git. It was only failing when I used repositories with git sub-repos.
In case others are having a similar problem with Git sub-repos:
Check that Git is installed correctly. I removed and re-installed it completely. (See: https://code.google.com/p/msysgit/downloads/list for latest version).
Ensure that the path to Git is in the path environment variable. (Right-click My Computer -> Advanced tab -> Environment Variables). Don't forget that some applications do not like windows paths with spaces in so you might need to replace "Program Files" with "PROGRA~1" (possibly "PROGRA~2" on 64-bit systems).
If you are using a proxy, ensure that HTTP_PROXY and HTTPS_PROXY in the environment variables are also set correctly.
I work with a partner on an PHP site for a client. We have a common Mercurial repository (on Bitbucket), both local copies and the live site. We have only FTP access to the live site (which can't be changed since it is a hosting package with FTP only).
I want to be able to push changes from the repository to the live site.
Until now I simply keep track of changed files in the repo and copy them manually with FileZilla - a error prone and annoying task. My idea is, to mount the remote location locally (i.e. using CurlFtpFS) and tell mercurial to automagically copy changed files to the site. Ideally I want to be able to specify which changes but this would be a bonus. It would be sufficient if the local state of the files within the repo are synced.
Is there any good way to do this using linux commandline tools?
My first recommendation is, if at all possible, get a package that allows more access. FTP only is just brutal.
But since you are looking for a real answer to your question, I have two ideas for you:
I would suggest looking into the mercurial FTP Extension. I personally have never used it since I have never gotten myself stuck in a ftp-only situation (not for a long time at least), but it looks promising. Looks like if you make sure that you tag your production releases it will work really well for you. (make sure to use the -uploaded param)
Also, if you only ever want the tip to be installed on your production env, then you could look at the suggestion Martin Geisler made on the bitbucket user group a few days ago. Basically his suggestion is to utilize bitbucket's "ping url" functionality. You would have to write a server-side script/url handler that would accept that ping, then fetch the tip from bitbucket (as a zip) and then unzip/unpack it. This is a bit complicated, but if you are looking for complete automation and the tip will always be the best this could work for you.
One notion is the use the hg archive command:
hg archive /path/to/curlftpsfs
which will put a snapshot of your repo in that location -- it will however overwrite any file already there.
Another option is to create a Mercurial clone in that same /path/to/curlftpsfs and then just do a hg pull ; hg update in it on your local system with the remote one mounted. Setting that up initially will mean transferring the whole thing but subsequently you'll only be sending deltas.
Some folks don't like this last options because it exposes your entire /.hg repository too, but you can block access to that at the web server.
I came across this problem a while ago after switching from AWS to a local web hosting that provides only ssh/ftp.
My previous approach of updating a production site on AWS using "hg pull; hg update -C" can no longer be used on the new web hosting. They don't have mercurial installed for shared hosts.
So, what I did is to mount the remote location using ftp, to a local machine (i.e. your laptop), then run the hg pull and update commands locally on your machine at the path where has the remote ftp site mounted.
Windows solution:
BeyondCompare (http://www.scootersoftware.com/) is an awesome piece of software. Apart from being awesome it can mirror your local folder to the FTP site. It's comparing files and only transfers what's new.
This is probably a simple problem and I'm feeling exceptionally dumb because I can't find a any kind of documentation.
I've just installed TeamCity 5 and I want to get files from my Mercurial hosting and there is two fields I just can't figure out.
HG Command path. What should I put here? The path to a file containing what? Can I get an example of that file somewhere?
The host is using Mercurial over SSH where do I define my private key?
Pull changes from? Should I put the address I'm cloning from i.e. ssh://username#myhost.something/project
I figured this out for my TeamCity 5 server last week.
HG Command path: HG
Pull changes from: https://bitbucket.org/.../.../
Don't put the username# in the URL. This is specificed as in the Username/Password fields. If you include the username in the URL it'll fail as there is a bug in the configuration tool. You'll also see a screenshot of the configuration attached to the thread:
http://www.jetbrains.net/devnet/message/5254640#5254640
I'd suggest getting things working with HTTPS and then moving to SSH if possible. This breaks things down into two easier to solve configuration problems. I used the following tutorial to get SSH going on my Windows client machine.
http://www.codza.com/mercurial-with-ssh-setup-on-windows
I've not set this up on my TeamCity server yet. However I did get TeamCity to pick up my Mercurial.ini settings by putting the ini file in \Documents and Settings\TeamCity, which is the account the service runs under.
I've not used team city, but I think hg command path is probably the full path to your local mercurial executable. For me (on linux) that's:
$ type hg
hg is /usr/bin/hg
On windows it's where the 'hg' executable in your system path was placed by whichever (of the many) windows installers for mercurial you used.
Pull changes from sounds like the URL to the repo, so:
ssh://username#myhost.something/project
or
ssh://username#myhost.something//project # note the _two_ double slashes
if you're using absolute paths on the server side.
Your private key location/specification depends on what you're using for ssh and whether or not you're running ssh-agent, but here's a links that explicitly points from within mercurial.ini, which seems sound:
http://dev.openttdcoop.org/projects/home/wiki/Configuring_TortoiseHg_(Windows)#Pointing-to-you-Private-key