Problems changing a BOINC server's name

The following email summarizes a problem that we had when we changed our server's name to make it available outside our firewall.

Solution found:

I wrote:

Okay we changed the name of our server from an internal name to an external one that can be accessed across the Internet. My problem is that bin/start reports:

Entering ENABLED mode
Starting daemons

And nothing happens. "ps aux|grep feeder" only reports the grep instance.

I have changed the server name in the mysql.user table, in /etc/sysconfig/network, in config.xml and I'm sure a few other locations. Restarted the machine, etc. I also verified the permissions on the new log_... and pid_... folders.

Found the problem. The 'stop_daemons' file was not being deleted by bin/start. I did not realize that the config.xml host setting should only be 'www'. Not the FQDN.

The config host has to match the localhost name that is internal to bin/start. This is *not* the same as what is returned by 'hostname'.

This took awhile to find, because no log files were being generated, neither did start report any errors. I only saw it by running feeder under gdb, where the output apparently goes to stdout/stderr instead of (or in addition to) the log file.

--
Ron Parker

UPDATE:
One additional file that needed changed in the SciLINC project directory was html/user/schedulers.txt.

It is also necessary to update the app_version table. The path to the application files on the server is hard coded in the XML data fields of this table. Running bin/update_versions will update it, but it may be necessary to first delete the rows that refer to the old server.

Visual Studio 2005 missing Msi.lib

Visual Studio 2005 only installs msi.lib for the AMD-64 platform. Installing the latest Platform SDK, PSDK will install it for x86, IA-64 and AMD-64. As of this post, Microsoft Platform SDK for Windows Server 2003 R2 was the most recent version. That page should say whether or not there is a more recent version.

Once it is installed, you have to tell Visual Studio where to find the PSDK files. The file path settings are part of the Visual Studio options which are accessed from the ToolsOptions... menu item.

Under Projects and Solutions, select VC++ Directories. Then, pick each item under Show directories for looking for paths have PlatformSDK in them. Insert an entry just before it that refers to the same subdirectory under $(ProgramFiles)\Microsoft Platform SDK for Windows Server 2003 R2.



The up- and down-arrow buttons may be used to move the new entry to the right place in the list.

Now, Rebuild any solution that needs the msi.lib library.

Importing Python Subversion Archive into Git

While it is not well advertised, it is possible to download a snapshot of the Python Subversion repository via rsync.

rsync -avP svn.python.org::ftp/pub/svn.python.org/snapshots/projects-svn-tarball.tar.bz2 .

Note: I discovered later that it can be downloaded by browser as well, http://svn.python.org/snapshots.

Once the file is downloaded expand it:

bunzip2 projects-svn-tarballs.tar.bz2|tar xf -

Then use git-svnimport to create the baseline git repository:


git-svnimport -v -C python.git -T python/trunk -t python/tags -b python/branches file://`pwd`/projects

Following this the archive may be brought up to date and kept upto date using:

git-svnimport -v -C python.git -T python/trunk -t python/tags -b python/branches http://svn.python.org/projects

Importing SourceForge Subversion Projects into Git

At least for the initial import it is faster to create a local mirror of the desired repository using rsync. Taking the Simplified Wrapper and Interface Generator project, SWIG, as an example:

rsync -avz rsync://swig.svn.sourceforge.net/svn/swig/* swig.svn

Made a copy of the Subversion SWIG repository in about 10 minutes.

(On CentOS 4, I had to upgrade svn from the source to be able to access this mirror. I installed the RHEL4 RPMs that were pointed to on the Subversion download page. I needed the apr, apr-util, subversion and subversion-perl packages.)

Then I was able to import this into a git repository using:

git-svnimport -C swig.git \
              file://`pwd`/swig.svn

This took about 13 minutes.

After importing a new repository, repacking recommended:

cd swig.git
git repack -a -d

This reduces the amount of space the repository requires. It can be significant on a large or active repository.

Future updates can then be done fairly effeciently from within the swig.git subdirectory with:

git-svnimport -C . https://svn.sourceforge.net/svnroot/swig

Because it is no longer needed, the swig.svn directory can now be deleted.

Just some statistics
While the rsync'd Subversion repository took up 238MiB, the git repository only used 63MiB. Most of this is the working copy of the code. The actual repository swig.git/.git only occupied 25MiB. (Barely a tenth of what Subversion required.)

Alternatives
While I could have run git-svnimport directly against the remote repository, this would have taken about 32 hours. Even using svm or SVN::Mirror in place of rsync would have required around 10 hours.

If you can use rsync or another tool to make a local copy of the repository, the import will run much more quickly.

Fixing Synergy Shift Behavior

When running the Synergy client on CentOS with a Window machine operating as the server, I had problems with the behavior of the [Shift] key. There was a delay from when [Shift] was pressed until it took effect and often the left [Shift] key would not take effect at all.

This was corrected by downloading, building and installing the latest source RPM from the Synergy site. You may have as much luck with the binary RPM. I just didn't try it.

Update: Fixed typo