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.
Related
So I'm running Ubuntu 14.04 on VirtualBox via Vagrant, and want to set up Mercurial so that it doesn't constantly ask for a password when pulling latest. In that regard, I've installed Mercurial-Keyring, and changed my ~/.hgrc file to look like:
[extensions]
mercurial_keyring =
[auth]
ono.schemes = https
ono.prefix = <URL>
ono.username = <username>
However, now it asks me to enter a password for the encrypted keyring every time I want to use Mercurial - even on the same session.
Does anyone know what the cause of this is?
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.
After installing and playing around with mercurial , I am trying to get Hudson to clone the repository so it can build my project.
At the moment the following task works.
I Can sync to my external host and the code shows up on that host.
Now I am trying to configure hudson / jenkins to access the code on my host.
But unfortunately I am rolling on a error:
Started by user anonymous
$ hg clone --rev default https://bitbucket.org/*/testproject "F:\Hudson\jobs\testproject\workspace"
abort: http authorization required
ERROR: Failed to clone https://bitbucket.org/*/testproject
[workspace] $ hg log --rev . --template {node}
java.io.IOException: Cannot run program "hg" (in directory "F:\Hudson\jobs\testproject\workspace"): CreateProcess error=267, The directory name is invalid
at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
at hudson.Proc$LocalProc.<init>(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:698)
at hudson.Launcher$ProcStarter.start(Launcher.java:329)
at hudson.Launcher$ProcStarter.join(Launcher.java:336)
at hudson.plugins.mercurial.MercurialSCM.joinWithPossibleTimeout(MercurialSCM.java:298)
at hudson.plugins.mercurial.HgExe.popen(HgExe.java:191)
at hudson.plugins.mercurial.HgExe.tip(HgExe.java:171)
at hudson.plugins.mercurial.MercurialSCM.calcRevisionsFromBuild(MercurialSCM.java:254)
at hudson.scm.SCM._calcRevisionsFromBuild(SCM.java:304)
at hudson.model.AbstractProject.calcPollingBaseline(AbstractProject.java:1186)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1175)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:523)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:418)
at hudson.model.Run.run(Run.java:1362)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
Caused by: java.io.IOException: CreateProcess error=267, The directory name is invalid
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.<init>(ProcessImpl.java:81)
at java.lang.ProcessImpl.start(ProcessImpl.java:30)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:453)
... 18 more
Finished: FAILURE
What actions do i need to do to tell Hudson to use username x and password y to acces the data?
Edited => Found how to integrate ssh .
Used SSH instead of https
Download putty.exe, puttygen.exe, pageant.exe, and plink.exe from the PuTTY website.
Start puttygen and generate a key in OPENSSH FORMAT (hudsons format) (=> How to use Svn + SSH )
Click the Save private key button and save the .PPK file somewhere.
Click the Save public key button and save it.
Go to your website and enter the public ssh-key
Run pageant.exe. The pageant icon (a computer wearing a hat) will show up in the status tray.
Right-click the pageant icon and choose Add Key.
Choose the .PPK file you saved earlier and type in its passphrase.
The following (end part is copied) from Ted Naleid (Thank you!) blog witch can be found here : Hooking up hudson to your ...
Install the Mercurial plugin in Hudson
All that’s left to do now is install
the Mercurial plugin in hudson. In a
browser, go to
http://INSERT_YOUR_IP_HERE:8080.
Hudson should come up.
Click on “Manage Hudson” and go to
“Manage Plugins”. Go to the
“Available” tab, check “Hudson
Mercurial plugin” and hit the
“Install” button. Hudson will prompt
you to restart, and then it’s
installed.
After that, just create a new job and
you’ll have a new “mercurial” option
in the “source control management”
section. Select that and put the ssh
URL in the “Repository URL” field.
Then put “default” in the “branch”
field and set up the rest of the job
to build/test your code (an exercise
left to the reader).
and here it is the first succesfull build !
Conclusion : This is a summary of all the small blogpost scattered arround the internet. I hope this post helps you in starting hudson and mercurial.
I think the problem is not related to username and password. Your stacktrace tells you there's something wrong with the path F:\Hudson\jobs\testproject\workspace.
Cannot run program hg (in directory
"F:\Hudson\jobs\testproject\workspace")
The directory name is invalid
Anyway, you can specify the username and password in the URL like: http://user:password#mydomain.org.
To authenticate the Jenkins/Hudson Mercurial plugin with BitBucket I too found it useful to use the SSH protocol instead of HTTPS particularly since:
there doesn't seem to be a way to store your HTTPS credentials to BitBucket with the Mercurial Jenkins plugin, but with SSH you can safely and securely store your credentials
with SSH you can configure it to use compression, which Mercurial doesn't do natively.
Good instructions for setting up SSH access to BitBucket are available here: http://confluence.atlassian.com/display/BITBUCKET/Using+SSH+to+Access+your+Bitbucket+Repository
Notes:
If you are running Jenkins/Hudson on a *nix server, you will want to login as the user running the Jenkins process and perform these operations from that users home directory, so the configurations will be found by that user (e.g. on my Debian server installation of Jenkins standalone, the user 'jenkins' is created and the home directory is set to '/var/lib/jenkins' [not /home/jenkins] - where I performed the instructions provided at the above link).
I found it very helpful to assure the hg clone command worked from the command line before attempting to have Jenkins call it.
IMPORTANT: In order to get this to work, I had to generate a key ** without ** a passphrase.
You can add the following lines to jenkins .hgrc file (usually /var/lib/jenkins/.hgrc)
[auth]
bitbucket.prefix = https://bitbucket.org/your_user/...
bitbucket.username = your_user
bitbucket.password = ******
See http://www.selenic.com/mercurial/hgrc.5.html#auth
You can add your scm credentials in the 'Credentials` section of Jenkins:
Also change the job configuration to use the credentials:
I use mercurial in my project, and every time I push new changesets to the server by ssh, it ask me for a password.
Then how to config the mercurial to push with out asking password?
I works on Ubuntu 9.10
On Linux and Mac, use ssh-agent.
Ensure you have an ssh keypair (see man ssh-keygen for details)
Copy your public key (from ~/.ssh/id_dsa.pub) to the remote machine, giving it a unique name (such as myhost_key.pub)
Log in to the remote machine normally and append the public key you just copied to the ~/.ssh/authorized_keys file
Run ssh-add on your local workstation to add your key to the keychain
You can now use any remote hg commands in this session without requiring authentication.
Assuming you're using Windows, have a read of my Mercurial/SSH guide. Down the bottom of the post you'll find info on how to use PuTTy to do this for you.
Edit: -- Here's the part of the post that I'm talking about (bear in mind you'll need to have pageant running with your key already loaded for this to work):
Client: Setting up Mercurial
If you haven't already, make sure you install Mercurial on the client machine using the default settings. Make sure you tell the installer to add the Mercurial path to the system PATH.
The last step of configuration for the client is to tell Mercurial to use the PuTTy tools when using SSH. Mercurial can be configured by a user-specific configuration file called .hgrc. On Windows it can also be called Mercurial.ini. The file is located in your home folder. If you don't know what your home folder is, simply open a command prompt and type echo %USERPROFILE% - this will tell you the path.
If you haven't set up your configuration yet, then chances are the configuration file doesn't exist. So you'll have to create it. Create a file call either .hgrc or Mercurial.ini in your home folder manually, and open it in a text editor. Here is what part of mine looks like:
[ui]
username = OJ Reeves
editor = vim
ssh = plink -ssh -i "C:/path/to/key/id_rsa.ppk" -C -agent
The last line is the key and this is what you need to make sure it set properly. We are telling Mercurial to use the plink program. This also comes with PuTTy and is a command-line version of what the PuTTY program itself does behind the scenes. We also add a few parameters:
-ssh : Indicates that we're using the SSH protocol.
-i "file.ppk" : Specifies the location of the private key file we want to use to log in to the remote server. Change this to point to your local putty-compatible ppk private key. Make sure you user forward-slashes for the path separators as well!
-C : This switch enables compression.
-agent : This tells plink to talk to the pageant utility to get the passphrase for the key instead of asking you for it interactively.
The client is now ready to rock!
Install PuTTY.
If you're on Windows, open projectdir/.hg/hgrc in your favorite text editor. Edit it to look like this:
[paths]
default = ssh://hg#bitbucket.org/name/project
[ui]
username = Your Name <your#email.com>
ssh = "C:\Program Files (x86)\PuTTY\plink.exe" -ssh -i "C:\path\to\your\private_key.ppk" -C -agent
If it's taking forever to push, the server might be trying to ask you a question (but it's not displayed).
Run this:
"C:\Program Files (x86)\PuTTY\plink.exe" -T hg#bitbucket.org -i "C:\Program Files (x86)\PuTTY\plink.exe" -ssh -i "C:\path\to\your\private_key.ppk"
Answer any questions, and then try pushing again.
If you're using Bitbucket, open your private key with puttygen, copy your public key out of the top textbox, and add it to your user account: https://bitbucket.org/account/user/USERNAME/ssh-keys/