.rvmrc trust hangs/freezes - rvmrc

I'm having problems trusting an rvmrc as a non-root user. If I cd to the project directory I get the rvm trust prompt
Do you wish to trust this .rvmrc file? (appdir/.rvmrc)
y[es], n[o], v[iew], c[ancel]>
but when I pick y[es] it hangs indefinitely. rvm rvmrc trust has similar problems.

I used set -x to figure out where rvm trust was freezing.
> set -x
> cd appdir
Do you wish to trust this .rvmrc file? (appdir/.rvmrc) y[es], n[o], v[iew], c[ancel]>
>y
..
..
..
/usr/local/rvm/scripts/db /usr/local/rvm/user/rvmrcs _usr_share_batsd_current__rvmrc delete
I then ran */usr/local/rvm/scripts/db /usr/local/rvm/user/rvmrcs _usr_share_batsd_current__rvmrc delete* with sudo. This removed the entry in /usr/local/rvm/user/rvmrcs. After that entry was delete I was able to trust the rvmrc.

Related

"Permission denied" when deleting files inside of .git folders

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.

Jenkins Mercurial not trusting file

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.

Cannot login to phpMyAdmin, no errors shown

I have MySQL set up correctly on my linux computer, however I want a better way to input data into the database besides terminal. For this reason, I downloaded phpMyAdmin. However, when I try to log in to the phpMyAdmin from index.php, it doesnt do anything. It seems to just refresh the page without doing anything. I am putting in the correct MySQL username and password. What is the issue?
Here is a screen shot of what it shows after I click "go".
This is a possible issue when the path to save php_session is not correctly set :
The directory for storing session does not exists or php do not have sufficient rights to write to it.
To define the php_session directory simply add the following line to the php.ini :
session.save_path="/tmp/php_session/"
And give write rights to the http server.
usually, the http server run as user daemon in group daemon. If it is the case, the following commands will make it :
chown -R :daemon /tmp/php_session
chmod -R g+wr /tmp/php_session
service httpd restart
Login fails if session folder in not writeable. To check that, create a PHP file in your web directory with:
<?php
$sessionPath = 'undefined';
if (!($sessionPath = ini_get('session.save_path'))) {
$sessionPath = isset($_ENV['TMP']) ? $_ENV['TMP'] : sys_get_temp_dir();
}
if (!is_writeable($sessionPath)) {
echo 'Session directory "'. $sessionPath . '"" is not writeable';
} else {
echo 'Session directory: "' . $sessionPath . '" is writeable';
}
If session folder is not writeable do either
sudo setfacl -R -m u:www-data:rwx <session directory> or chmod 777 sudo setfacl -R -m u:www-data:rwx <session directory>
-
I am late to the game, but on Amazon linux AMI I could not log in to phpmyadmin ... it just kept refreshing the login screen with no errors.
I have fixed with below command
sudo chmod -R 755 /var/lib/php/session
I fixed my issue on CentOS 7 with MariaDB and phpmyadmin I downloaded from offical phpmyadmin site by adding
session.save_path = "/var/lib/php/session"
to /etc/php.ini
and
chown -R :lighttpd /var/lib/php/session
I also restarted php-fpm and lighttpd after
In my case the solution was to set an Apache setting properly:
ProxyPassReverseCookiePath
This was required, because ProxyPass and ProxyPassReverse were in use, but cookie paths are not changed automatically.
It'd be great if PHPMyAdmin had shown something like session not found or anything, when password is sent with POST.
Do you have a .htaccess file in one of the parent directories that strips off index.php from the url by doing a 301 redirect?
301 redirects discard the form data and redirect you as if you didn't submit anything. So you get returned to the login page.
So you should create a local .htaccess file in the phpmyadmin directory with a single line RewriteEngine On. This will overwrite the previous rewrite rule to nothing.
You may need to clear the browser cache as Chrome aggressively caches 301 redirects.
In my case the hard drive was full.
Use df -h to check the space left on your hard drive, and if you want you can free some space by using the command sudo apt-get clean, which removes installation files.
I hope this will help some future users.
I ran these commands and it worked for me:
sudo service httpd restart
sudo service mysqld stop
sudo service mysqld start
Try searching the web for installation or setup guides for phpMyAdmin. Look at two or three of these and make sure you have covered all the required steps. (If you have already done so, please include which guides you have followed it in the question).
See if it helps to edit config.inc.php (acecoder mentioned this as well).
Check if this guide is of any help.
Which distro are you on? Try searching for the name of the distro you are using together with "phpMyAdmin guide" or "phpMyAdmin setup howto".
If you encounter errors along the way, post the error text here, if it's short (or paste via a pastebin-like site if it's long).
Are you sure that mysql is running? I had the same issue after doing a database import and filling up the volume containing the mysql database. After changing various permissions and clearing sessions, I tried to restart mysql (/etc/init.d/mysql restart) and it failed because the volume was full. After increasing /var and starting mysql successfully, I was able to log into phpmyadmin just fine.
If you have an error like:
Host 'host_name' is blocked because of many connection errors.
Login in your mysql as root and run the flush hosts command
1.- mysql -u root -p
2.- mysql > flush hosts
After this I was able to login again in phpmyadmin
phpMyAdmin will show errors when login fails. If it doesn't, it means that your setup has an error.
The most likely place to check is your php.ini settings. Since there doesn't seem to be an official list of phpMyAdmin-compatible settings, it's mostly trial and error.
Make sure you have enabled the stuff that needs to be enabled. Also check that you did not enable uncommon php.ini settings (like enable_post_data_reading = Off) because phpMyAdmin assumes them to be "the usual ones".
To ease debugging, start with a clean default php.ini file then tweak them line by line to see which setting is causing the error. (Don't forget that you need to restart your server after changing the php.ini file for the changes to take place.)
In my case it was due to an old Apache session.
Stop Apache, clear all pending sessions in your sessions.save_path directory (example: /var/lib/php/session) and restart Apache.
Make sure to set a 32 chars long random key in 'config.inc.php' in the $cfg['blowfish_secret'] value. That solved it for me.
Didn't realize I need to restart MariaDB after modifying config.inc.php:
service mariadb restart
Otherwise at least in my case changes didn't come affect. Also make sure your php session directory is writable by webserver (typically session.save_path = "/var/lib/php/session")

How to config mercurial to push without asking my password through ssh?

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/

How can I get hg to prompt for my HTTP auth username / password on cygwin / windows?

At home, this works perfectly. I'm on another computer now (using cygwin) and hg push will not prompt for a username / password:
user#localhost /cygdrive/d/repos/upthescala/viewprotect
$ hg push https://viewprotect.googlecode.com/hg/
pushing to https://viewprotect.googlecode.com/hg/
searching for changes
abort: http authorization required
Here are the contents of my ~/.hgrc:
[http_proxy]
host=someproxy:8080
[ui]
username = My Name <myemail>
Thanks in advance for any advice!
Note: this seems to be a cygwin problem. When I try from the Windows prompt (cmd.exe), it works as expected:
D:\repos\upthescala\viewprotect>hg push https://viewprotect.googlecode.com/hg/
pushing to https://viewprotect.googlecode.com/hg/
searching for changes
http authorization required
realm: Google Code Mercurial Repository
user: myemailaddress
password: *********
remote: Success.
--
LES
This could be caused by using a version of Mercurial that's tied to the Windows console subsystem. The binary distributed with Tortoise falls into this category. If this is the case, mercurial is expecting to use the console subsystem to prompt for credentials, but it does not find it when run from the Cygwin shell. In my case, installing and using the Cygwin version of mercurial fixed the problem, in addition to fixing color output. To check which version you're using, run 'which hg' (but you probably already knew that).
To add to Andrew's comment:
installing and using the Cygwin version of mercurial fixed the problem,
This also fixed the problem for me, but it caused another problem which took me some time to figure out. When using the Cygwin version of hg, all files that had been cloned under TortoiseHG showed up as modified when I ran hg status, but no differences were shown for any of them when I ran hg diff.
The problem was that the permissions didn't match. Running chmod 644 .* -R in each repo resolved this problem.
Since it's HTTP you can always put the username and password right in the URL. That works on any website using http auth and in any browser.
hg push https://myemailaddress:*********#viewprotect.googlecode.com/hg/
Alternately, newer Mercurial versions have an auth section you can use.
BTW, that's a terrible password. You should come up with something better than eight stars.