Source Server (or local system)

Generate RSA key for user on this system, you can also use DSA.  This asks for key pass-phrase but you can leave it blank.

ssh-keygen -t rsa

This asks for location to place the generated key, by default it will be your home directory (ex: /home/your_username/.ssh/).  This generates two files:  id_rsa and id_rsa.pub.  Content of id_rsa.pub is what we need to copy to destination server.

Destination Server (or remote server)

Check if you have the directory .ssh on your home (ex: /home/username/.ssh/), if not, create that directory.

ls  ~/.ssh
mkdir  ~/.ssh

Check if you have existing file authorized_keys on your .ssh directory, if not create it.

ls  ~/.ssh/ authorized_keys
touch   ~/.ssh/ authorized_keys

Copy content of id_rsa.pub that you created from your source/local server, or execute this command from your source/local server:

scp  ~/.ssh/id_rsa.pub username@remote_host:~/.ssh/authorized_keys

Test your password-less login from source to destination server.

Server: Locate sftp-server binary and add to your list of valid shells on the system.

which sftp-server

Note:   This will most likely give you this: /usr/libexec/openssh/sftp-server

echo /usr/libexec/openssh/sftp-server >> /etc/shells

Note:  You may want to backup your /etc/shells first

User Accounts:  Add or modify accounts to use sftp-server.

New User

useradd -s /usr/libexec/openssh/sftp-server  sftponlyuser

Note:  Important parameter there is the “-s /usr/libexec/openssh/sftp-server”, which sets the default shell for this account.   By default you will have “/bin/bash”.

Existing User:

vi /etc/passwd

Find the user that you want to configure for sftp only access and edit its shell.  For exampleyou will see a line “username:x:500:500::/home/username:/bin/bash” change “/bin/bash” to “/usr/libexec/openssh/sftp-server” and save.  Note: You may want to backup your /etc/passwd file as well.

Let’s assume you already moved the databases (separate database for Drupal and CiviCRM as a recommended setup) and the files to new location and have set the correct file permissions as well. Here is the part that you need for your CiviCRM to work on new location and domain:

• access your database and empty civicrm.domain:config_backend. You see this anywhere with CiviCRM guide.
• update database details, site path/directory, and domain on civicrm.settings.php
• emtpy sites/default/files/civicrm/template_c (or make this entire dir writable by web user)
• login to you new Drupal site and visit these urls:
  http://sitename/civicrm/menu/rebuild?reset=1
http://sitename/civicrm/admin/setting/updateConfigBackend?reset=1
  Note: This will rebuild the settings for you – if not, repeat/review all the above steps.

You can quickly see available shortcut keys by typing “?” (question mark, no qoutes) and it will give you this screen.

Of course you need to enable keyboard shortcuts on your settings.

And finally:
rm -vf $LIST

Hmm… looking at the respective path I can see that the command is not lying and that file fsfs.conf is indeed not present. I could find a file fs-type but not fsfs.conf. So my only assumption was that this is an older repository created with an older svn version than the one we were running currently. Checking the existing svn version I got:
svn --version
svn, version 1.6.11 (r934486)
compiled Apr 20 2010, 00:24:22
and the fact that this repo was very old (~2009) made my assumption sound correct. Ok, now what? Well in this situation my first thought was to use the svnadmin upgrade command; from the manual it looked like this is what I needed to fix this issue:

“svnadmin help upgrade
upgrade: usage: svnadmin upgrade REPOS_PATH

Upgrade the repository located at REPOS_PATH to the latest supported
schema version.

This functionality is provided as a convenience for repository
administrators who wish to make use of new Subversion functionality
without having to undertake a potentially costly full repository dump
and load operation.  As such, the upgrade performs only the minimum
amount of work needed to accomplish this while still maintaining the
integrity of the repository.  It does not guarantee the most optimized
repository state as a dump and subsequent load would.”

After I’ve made a manual backup archive of the repo (a simple tar.gz of the repo folder) I ran the upgrade command sure this is going to fix my issue:
svnadmin upgrade /svn/repo/
and after it completed, I verified that svn was still working as expected and checked for the fsfs.conf file. But that was not created… Hmm… Let’s try the hotcopy command anyway:
svnadmin hotcopy --clean-logs /svn/repo/ /tmp/repo/
svnadmin: Can't open file '/svn/repo/db/fsfs.conf': No such file or directory
the exact same error.

Trying to understand what the fsfs.conf file contains I just created a new repository to see if it gets created. Indeed my v1.6.11 of svn created the file for a new repo, and after copying it to the location of my existing repository (as it was basically just an empty file) my issue was fixed and the hotcopy command started working. Here is the content of the file as created by my svn version, that I copied in the older repo to fix this problem:

cat fsfs.conf
### This file controls the configuration of the FSFS filesystem.

[memcached-servers]
### These options name memcached servers used to cache internal FSFS
### data.  See http://www.danga.com/memcached/ for more information on
### memcached.  To use memcached with FSFS, run one or more memcached
### servers, and specify each of them as an option like so:
# first-server = 127.0.0.1:11211
# remote-memcached = mymemcached.corp.example.com:11212
### The option name is ignored; the value is of the form HOST:PORT.
### memcached servers can be shared between multiple repositories;
### however, if you do this, you *must* ensure that repositories have
### distinct UUIDs and paths, or else cached data from one repository
### might be used by another accidentally.  Note also that memcached has
### no authentication for reads or writes, so you must ensure that your
### memcached servers are only accessible by trusted users.

[caches]
### When a cache-related error occurs, normally Subversion ignores it
### and continues, logging an error if the server is appropriately
### configured (and ignoring it with file:// access).  To make
### Subversion never ignore cache errors, uncomment this line.
# fail-stop = true

[rep-sharing]
### To conserve space, the filesystem can optionally avoid storing
### duplicate representations.  This comes at a slight cost in performace,
### as maintaining a database of shared representations can increase
### commit times.  The space savings are dependent upon the size of the
### repository, the number of objects it contains and the amount of
### duplication between them, usually a function of the branching and
### merging process.
###
### The following parameter enables rep-sharing in the repository.  It can
### be switched on and off at will, but for best space-saving results
### should be enabled consistently over the life of the repository.
# enable-rep-sharing = false

Hopefully this will help others seeing the same issue I was experiencing.

I’ll assume that you have installed apc already, if this is not the case this will probably be something as simple as running
pecl install apc
or downloading the archive from pecl and running:
phpize; ./configure; make; make install

The APC extension needs to be enabled either in php.ini or in one included file with a line like this:
extension=apc.so
there are many other parameters that apc can be fine tuned (see the official doc for more info), but without any other change, just with this line apc will be enabled on all the vhosts on the server.

Disabling some vhosts from using APC
- if we want to disable APC for a particular vhost we just have to add to the vhost config or to .htaccess:
php_flag apc.cache_by_default Off

Enabling APC only on some vhosts
- if we want to have APC disabled by default globally we will have in php.ini:

extension=apc.so
[apc]
apc.cache_by_default=0 # disable by default
... other apc settings...

and we will enable APC for the particular vhost config or using .htaccess using:
php_flag apc.cache_by_default On

Hopefully you found this post useful and this will give you a reason to use APC with more confidence knowing that you have the granularity to disable/enable it as needed in a shared environment.

The problem is on the copied site that is on a new domain as we cannot login and go to the admin section because it redirect back to the source/original site. What we need is either disable the securepages module or update the domains. To do this, you need to access your database (ex: phpmyadmin, etc), go to variable table, and search for securepages configurations.

If you want to disable the module change:
securepages_enable s:1:"1";
to
securepages_enable s:1:"0";

Or if you want to update the domain change:
securepages_basepath s:30:"http://www.domain.com";
securepages_basepath_ssl s:31:"https://www.domain.com";
to
securepages_basepath s:30:"http://www.newdomain.com";
securepages_basepath_ssl s:31:"https://www.newdomain.com";

After making the above changes don’t forget to run the update.php (http://www.newdomain.com/update.php)

If you want to uninstall the module, try removing the securepages directory and run update.php.

What we did to eliminate this issue and be able to update the site automatically was Buy Ampicillin to create a copy of the original core modules (located in /modules), add our custom functionality, and put the modified copy into ‘contributed’ modules directory (/sites/all/modules). Drupal read the modules found on /sites/all/modules first and ignore the same copy (original) found on /modules. Also, may want to change the module info or the package name to separate the modified modules from the original ones – ex: modified_core, custom, etc. In the case that Drupal reads both of them, you can just disable the other one.

Here’s our policy on working with Drupal modules:
– contributed or community modules at /sites/all/modules
– custom made modules at /sites/all/modules/custom
– modified core modules at /sites/all/modules/core_modified

Hope this helps.

Ok, I got the error above when I performed Drupal CVS update on our Debian server (newly installed CVS 1.12.13). The same command works on other server with older CVS installation. The issue is the reference to local cvs directory where I used absolute path (-d /path/drupalsite/), which is a bug (security hole on client side) – it was fixed on newer CVS version to use relative path.

Drupal Checkout Command:
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d /path/drupalsite/ drupal

Use of Relative Path (sample)
cd /path
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -r DRUPAL-6-15 -d drupalsite drupal