We generally access our CVS server via Eclipse. One of our teammates, steveo created a new package Testing under our Java src folder for project ProjectName.
Afterwards, this caused failures with all checkouts for ProjectName.
The server reported an error while performing the "cvs checkout" command.
: cvs checkout: failed to create lock directory for `/app/cvs/repository/Main/ProjectName/src/Testing' (/app/cvs/repository/Main/ProjectName/src/Testing/#cvs.lock): Permission denied
: cvs checkout: failed to obtain dir lock in repository `/app/cvs/repository/Main/ProjectName/src/Testing'
: cvs [checkout aborted]: read lock failed - giving up
I putty'd to the CVS server and did an ls -l on the src folder
drwxrwxr-x 5 root cvs 4096 May 19 12:05 com
drwxrwxr-x 3 steveo steveo 4096 May 19 12:05 Testing
I sudo su, backed up to the project folder, and ran chgrp -R cvs ProjectName.
drwxrwxr-x 5 root cvs 4096 May 19 12:05 com
drwxrwxr-x 3 steveo cvs 4096 May 19 12:05 Testing
This has solved the issue for now... until another user creates a package.
What is causing this and how do I default them all to cvs instead?
The answers to this similar SO question were not helpful.
Figured it out and posting the answer for posterity.
I was originally going to set the repository folder to group cvs and make it sticky via chmod g+s /app/cvs/repository/, but that is not recursive and I don't know that I want to mess with that.
Default group id (GID) was not cvs for the users. The solution is a bit of a workaround as we're using Active Directory as our account login. Luckily, we're only using this server for CVS, which makes the solution simple.
This must be done for each account and each new account.
Make sure the account has attempted a log-in against CVS via Eclipse/RAD (and checked out a project, perhaps). This creates the user profile under home.
sudo su
cd \home\{username}
Since we have nothing else going on in it, echo "newgrp cvs" >> .profile
That will set the default group to cvs for the offending accounts on log-in and I can call it a day... and eventually migrate to Git / BitBucket.
Related
I'm getting an error in my self-hosted github runners:
rm: cannot remove '/home/user/github-actions/1/_work/project/project/.git/index': Permission denied
It's not just this one file, but all the files that it tries to delete.
If I run something like: sudo chmod -R 777 . in the home directory, it will temporarily fix it. But the issue will come back. What can I do to fix this permenantly?
When your runner fails with this error, double-check the output of:
ls -alrth /home/user/github-actions/1/_work/project/project/.git/index
ps -eaf|grep -i runner
That way, you can see:
who has created that file
what user is executing the current runner process
That allows you to confirm a user process issue (one executing the runner, the other the files).
I wonder if Git is running as a separate user or something
No, it should not.
I am trying to push a second version of my app (nodeJS + MongoDB) into my OpenShift account. It worked the first time, but now it fails with this error:
Erics-MacBook-Air:rippleRating ericg$ git push openShift master
Counting objects: 129, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (129/129), done.
Writing objects: 100% (129/129), 28.09 KiB | 0 bytes/s, done.
Total 129 (delta 94), reused 0 (delta 0)
remote: Stopping NodeJS cartridge
remote: Mon Apr 13 2015 07:53:08 GMT-0400 (EDT): Stopping application 'ripplerating' ...
remote: Mon Apr 13 2015 07:53:09 GMT-0400 (EDT): Stopped Node application 'ripplerating'
remote: Stopping MongoDB cartridge
remote: No such file or directory - /var/lib/openshift/xxxxxxxxxxxxxxxxf8000090/app-deployments/2015-04-13_07-53-10.382/metadata.json
To ssh://xxxxxxxxxxxxxxxxf8000090#ripplerating-<domain>.rhcloud.com/~/git/ripplerating.git/
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://xxxxxxxxxxxxxxxxf8000090#ripplerating-<domain>.rhcloud.com/~/git/ripplerating.git/'
If I rhc ssh to my app, I don't see the directory 2015-04-13_07-53-19.382, I have only app-files, current and by-id (app-files has the metadata.json).
BTW what would be a good place to add some files (secret.json) that I don't want to put in the git repo and can be used by the nodeJS app?
Thanks!
I recently came across this problem myself and wanted to share how I came to a solution.
To start, my /app-deployments directory contained the following:
by-id current redis-cli
Using ls -l reveals that current is actually a soft link to the currently running build.
current -> 2015-07-10_22-45-22.964
However, using the command file current also revealed that:
current: broken symbolic link to `2015-07-12_22-45-22.964'
That seemed strange, but it was consistent with the fact that there was no folder in the /app-deployments directory named with the most recent build's timestamp (2015-07-10_22-45-22.964). I removed current and attempted to push. Same result as the OP however, missing folder or directory for the new build with metadata.json inside.
After poking around in by-id and redis-cli, I found that redis-cli contained it's own metadata.json file with a lot of null values in it (both 'git_sha1' and 'id' were null). I played with the git_sha1 field to match both my previous and new commits, but nothing changed. The other folder, by-id, had a soft link in it as well which pointed to the redis-cli folder.
At this point I had backed up everything I wanted and I attempted to force a refresh to defaults of the /app-deployments directory by deleting everything in it and pushing. Surprisingly, it worked! Now my /app-deployments directory looks like this:
2015-07-10_22-45-22.964 by-id current
which is what I normally expect to see in there. Hopefully this will be helpful to someone!
As a side note, I later decided to enable openshift's support for multiple rollback versions, which you can read about here. It allows you to specify how many rollbacks you want to keep, which could be very valuable in another situation like this.
I finally got to the bottom of this one. I had created a folder under app-deployments, and that upsets the auto deployment logic in OpenShift. The current folder was deleted under app-deployments and I have to recreate it and put a metadata.json copy in it. Once I have done that I was able to deploy again using git push. I am gessing that if you have some secret data that cannot be kept in the git repo, they have to reside under app-root/data although this won't work for a scalable app... which in this case I am not sure where should I put those sensible data...
My answer is basically the one provided by #Will.R but shorter:
The problem comes from the fact that:
* app-deployments/current is a broken symbolic link to the most recent build.
If you want to fix this problem:
* Delete everything inside /app-deployments
* Push again
* :)
* Problem fixed.
I using mercurial and I am trying to point Jenkins toward custom directory. I ran into this error,
Started by user Netro
Building in workspace <path-to-workspace>
[workspace] $ hg showconfig paths.default
ERROR: Workspace reports paths.default as Not trusting file <path-to-workspace>/.hg/hgrc from untrusted user root, group root
Not trusting file <path-to-workspace>/.hg/hgrc from untrusted user root, group root
which looks different than http://ip-address/project so falling back to fresh clone rather than incremental update
ERROR: Failed to clean the repository checkout
I had searched internet and it suggested add trusted field. I had tried with following code in ~/.hgrc, /etc/mercurial/hgrc, <path-to-workspace>/.hg/hgrc
[trusted]
users = jenkins, root
But it doesn't remove error.
When I was not using custom directory option. It ran successfully.
Installation of Jenkins and repository was done with user root on Ubuntu 1204.
Any suggestions will be helpful.
It seems, hg was not able to accept jenkins as owner of the projects. Jenkins in default directory creates workspace with user Jenkins. So it is able to run it. I added Jenkins in group root and changed the owner of project from root to jenkins. Now projects are updated from Jekins.
I have hgweb.wsgi setup on an ubuntu server under apache2. Furthermore I have basic authing using the apache2 htpasswd approach. This all works nicely. However, we want to control what each user have access to and ACL seems to be the best approach. So inside the repos .hg folder I've created a hgrc and modified it according to the documentation for getting ACL up and running ( I've also enabled the extension ). The problem is I get no indication that the hgrc is used at all. If I add [ui] debug = true I still get nothing from the remote client. Sadly I'm not quite sure how to go about debugging this so any help would be much appreciated.
To make sure that a .hg/hgrc file in a repository is being consulted add something noticable to the [web] section like:
[web]
description = Got this from the hgrc
style = coal
name = RENAMED
If you don't see those in the web interface your .hg/hgrc isn't being consulted, and the most common reason for that is -- permissions. Remember that the .hg/hgrc has to owned by a user or group that is trusted by the webserver user (usually apache or www-data or similar). If apache is running under the user apache then chown the .hg/hgrc file over to apache for ownership -- root won't do and htpasswd user is irrelevant.
If that file is being consulted then you need to start poking around in the apache error logs. Turning on debug and verbose will put more messages into the apache error log, not into the remote client's output.
The repository is owned by user root, and group dev
Another user is running hg update on the repository and getting the following messages:
Not trusting file /dev/.hg/hgrc from untrusted user root, group dev
Not trusting file .hg/hgrc from untrusted user root, group dev
Not trusting file /dev/.hg/hgrc from untrusted user root, group dev
Not trusting file /dev/.hg/hgrc from untrusted user root, group dev
abort: Permission denied: /dev/src/backend/java/com/tt/afr/schedule/service/ScheduleComparator.java
In /etc/mercurial/hgrc, we have:
trusted.users=root
In the home directory of user running hg update, we have this hgrc file:
[trusted]
users = root
groups = dev
User is connecting to server using ssh and running the commands.
What can we do to fix this?
Please read the help on trust in Mercurial and make sure that you've added the trust settings on the server. When you connect over SSH, it does not matter who you trust or don't trust locally — it's the hg binary that you run on the server (via the SSH tunnel) that needs to trust the config file.
Also note that you need to put
[trusted]
users = root
in the /etc/mercurial/hgrc file on the server. The section.key = name syntax we use when talking about configuration settings only work on the command line.
For everybody else who has added this solution to their /repo/.hg/hgrc and nothing happened, this solution worked for me:
https://j.ee.washington.edu/trac/gmtk/ticket/33
Add in /etc/mercurial/hgrc.d/trust.rc
[trusted]
groups = yourgroup
users = youruser
Essentially, writing permissions to /repo/.hg/hgrc will not work, because the file itself is owned by an untrusted user.
Based on the answer by DustWolf, this works on Ubuntu under WSL (Windows Subsystem for Linux) using a Windows drive letter share mounted using Microsoft's WSL drvfs file system driver, i.e., hg running locally on a shared drive.
not trusting file /mnt/x/repo/.hg/hgrc from untrusted user root, group root
Mercurial Distributed SCM (version 5.3.1)
(see https://mercurial-scm.org for more information)
Copyright (C) 2005-2020 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Create trust.rc on the WSL machine:
sudo touch /etc/mercurial/hgrc.d/trust.rc
sudo nano /etc/mercurial/hgrc.d/trust.rc
Add:
[trusted]
groups = root
users = root
Save trust.rc and hg should now trust the repo hgrc as WSL's drvfs driver mounts the share as root:root.
wsl wsl-drvfs
Not your case, but might be worth a hint:
I had this error in a local container that was setup to migrate repos from hg to GitLab. Solved it by just by changing the ownership of the .hg directory in the downloaded hg's repository folder to root user/group:
chown -R root:root .hg
And the message not trusting file /data/hg-repo/.hg/hgrc from untrusted user 1000, group 1000 was gone.