SVN repository on bluehost

[vt88rider]

I've also verified the path problem pointed out by Teamhot by using plink. It appears that the .bashrc is no longer being run for non-interactive logins (e.g. ssh)? I assume .bashrc was being run before, since that's where I set the path to the svnserve command.

[teamhot]

Yeah the problem is definitely that .bashrc (and .bash_profile) are no longer being sourced on an svn command.

This is a pretty basic thing that I hope Bluehost can fix soon. I get the impression that they don't even know what's happening when people complain that their svn commands no longer work. Recompiling subversion is not going to fix anything, and telling people to do so just shows their ignorance in the matter.

[i18n]

I jsut sent this message to support. It might shed at least some light in folks here finding a workaround. I would give some ideas a try, but it is well past bedtime for me tonite....

=-------------------------
I jsut sent a message on this, no response yet.

But I was browsing your forum, and I am defintiely having the same issue reported on this thread: http://www.bluehostforum.com/showthr...rcurial&page=5
starting with post #41.

Clearly what is happening is that some changes, either a recompile, upgrade, or change to config was made to sshd about 2 weeks ago.

Now, when we run a remote command via ssh (I am using mercurial, others are reporting remote subversion repositories behave the same way) then either ~/.bashrc or ~/.bash_profile are not being run.


Some further digging reveals:

from: > man bash:

When bash is started non-interactively, to run a shell script, for
example, it looks for the variable BASH_ENV in the environment,
expands its value if it appears there, and uses the expanded value
as the name of a file to read and execute. Bash behaves as if the
following command were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the
file name.

when I check the remote environment I see that NBASH_ENV is not set:

$ ssh -l username domainname.com set
username@domainname.com's password:
mount: No such file or directory
BASH=/usr/bin/bash
BASH_ARGC=()
BASH_ARGV=()
BASH_EXECUTION_STRING=set
BASH_LINENO=()
BASH_SOURCE=()
BASH_VERSINFO=([0]="3" [1]="2" [2]="25" [3]="1" [4]="release" [5]="x86_64-redhat-linux-gnu")
BASH_VERSION='3.2.25(1)-release'
DIRSTACK=()
EUID=2551
GROUPS=()
HOME=/home1/username
HOSTNAME=box421.bluehost.com
HOSTTYPE=x86_64
IFS=$' \t\n'
LANG=en_US.UTF-8
LOGNAME=username
MACHTYPE=x86_64-redhat-linux-gnu
MAIL=/var/mail/username
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/bin:/bin
PPID=25977
PS4='+ '
PWD=/home1/username
SHELL=/bin/bash
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=1
SSH_CLIENT='99.58.167.75 43209 22'
SSH_CONNECTION='99.58.167.75 43209 69.89.31.221 22'
TERM=dumb
UID=2551
USER=username
_=bash

This is improper behavior, especially since they were being run before. Now it is killing some of your customers, such as me.

Can you provide a workaround or solution please.

One possible workaround seems to be hinted at here: http://fixunix.com/ssh/73472-openssh-umask.html

In this case, if you have your sshd_config with PermitUserEnvironment yes and restart sshd then it appears a user such as me can create a ~HOME/.ssh/environment
file with the following line in the file:

BASH_ENV=~HOME/.bashrc

and I should be good to go.

Perhaps your sshd config is already set up this way?

Is there another workaround?

[paperklip]

I got this response from my support ticket:

We recently upgraded OpenSSH on the server to the latest version.
 Unfortunately the update caused .bashrc to be no longer run for 
non-interactive sessions. Our admins are currently working on resolving this
 issue.

Thank you,
Scott
Technical Support Engineer
BlueHost.com
888.401.4678

and also:

I'm sorry there currently is no ETA on a resolution.
 I apologize for the inconvenience that this will cause you.

Thank you,
Bryce
Tech Support Engineer

[i18n]

I got the same messages.

Unlike tech support, I care about you.

I mentioned in my previous message that there were the seeds of a workaround in there, and now that I have rested up, I have tested it and am going to share it with you.

The problem is as Scott stated. I haven't dug deep enough yet to see what setting is wrong as an admin (I run my own Linux servers -fedora and RHEL too), but as a user you can get around it.

Before, if you did:

$ssh -l username domain command

it didn't work because .bashrc or .bash_profile was not being run.

but if instead you do:

$ssh -l username domain source .bash_profile;command

then you will have the right environment.

For example, see the difference in output between:

$ssh -l username domain env

and

$ssh -l username domain source .bash_profile;env

Hope this helps some people.

Hasn't completely solved my problem though because my source code control commands make the ssh command directly on their own behalf. I am using mercurial, some of you are using subversion, but the issue is pretty much the same.

[i18n]

OK, you guys can thank me with karma for this if it works for you

I am using hg, not svn.

My solution is hg specific but svn might have something similar.

hg has a config file for the user called ~/.hgrc.

In there, you can set the actual remote command to be executed, specifying the path.

See: http://mercurial.selenic.com/wiki/FA...ight=%28ssh%29

under question: I get an error while cloning a remote repository via ssh

In my case, I have set my .hgrc file up to force it to run .bash_profile by doing this:

$ cat .hgrc
[ui]
remotecmd=source .bash_profile;hg

and Voila, back in business!

I will point the folks on my ticket back to this thread, and the general command workaround and hg specific workaround, perhaps they will notify you that there is something they know about that will help.

And if any of you can work through the svn issue from here and post the solution, I am sure someone will be grateful!

[SuaveMonkey]

Outstanding. What an awesome community!

Will try altering ~/.ssh/authenticated_keys and ~/.ssh/authenticated_keys2 to use this extra command.

Recall that in these files, you store one or more public keys. Each key can contain a specific command to restrict what you can access while using this key. There's a "command=..." syntax that came up in this thread or elsewhere.

What is odd is that I've already tried the "command=" syntax in these files, even with a hard-coded svnserve command. But this still didn't work. Maybe I was using this syntax incorrectly. Maybe the file permissions weren't correct. Or some similar mistake.

Anyone else have luck with internationalization's (i18n's) trick?

[Shiro]

I've been having troubles with my .svn recently as well. After many hours of research, I just come to the realization myself that my .bashrc and .bash_profile aren't being run. So I opened a ticket with bluehost and they told me this:

This is due to a recent update to ssh that disabled the ability to source the .bashrc and .bash_profile during non-interactive sessions.

Additionally, there is a possibility that we may enable the use of the "PermitUserEnvironment" variable in the future. The general feeling, however, is that since this feature is disabled by default we will need to do some more research into why it is not enabled by default and go from there.

I am sorry for any trouble that this may have caused. Please let us know if there is anything else that we can help you with or if you have any further questions.

I'm screwed. My company has 6 or 7 accounts with bluehost, all running svn, and I use one of the servers as my central repository. If .svn doesn't work I'm going to have to switch all our servers to another company. What a huge hassle!

I found this thread after opening my ticket, so I'll keep looking at it. I sure hope that someone finds a solution, I hate switching hosts.

[Shiro]

What is odd is that I've already tried the "command=" syntax in these files, even with a hard-coded svnserve command. But this still didn't work. Maybe I was using this syntax incorrectly. Maybe the file permissions weren't correct. Or some similar mistake.

Anyone else have luck with internationalization's (i18n's) trick?

I've just spent the last hour playing with it. The closest I could come was adding the following to the start of my authenticated_keys2:

command="~/bash_profile"

But it said that I didn't have permissions to do that.

[Shiro]

I got it!

First I have to explain my setup, as the solution I came is specific to my setup.

* Machine: windows (XP)
* SVN client: tortoise svn
* command line client: putty
* Using private and public keys to login to the server
* public key file on server is .ssh/authorized_keys (this may be .ssh/authorized_keys2 for some people)

To get tortoise to properly connect to the server, I edited authorized_keys. Originally it looked like this:

ssh-rsa [key omitted]

I edited it to look like this:

command="~/bin/svnserve -t" ssh-rsa [key omitted]

If you installed svn at a location other than ~/bin, you will have to change this accordingly.

This allowed tortoise to work, as tortoise automatically uses the settings saved within putty for the server name. However, I wasn't able to open an interactive shell through putty this way. So what I had to do was generate another private/public key combo. I saved the public key to authorized_keys, and saved the private key on my machine. Then I opened putty, and created a new setting that used the new private key. I saved this with an abbreviated name, so that tortoise wouldn't pick up on it when trying to connect with the server.

So now I have both tortoise and putty connecting with my svn server again. Success!