Small Server Tools/Scripts

SourceForge.net Logo

This project is a collection of some small server tools/scripts that I have had to build for my needs. They are so small and simple and easy to build that I think that they may have been invented and re-invented many times by other programers. But maybe because they are so small, people think that it is not worth to publish them, so I couldn't find anything similar when I needed to use something like them. I collected them in a single project, since I think that it is not worth to create a separate project for each of them. They are here for the sake of collection and in order to help anybody else that needs to use or build any similar tools. All of them are free software (GNU GPL).

  1. Copying
  2. PHP Looking Glass (phplg)
  3. Uploading Files (upload)
  4. Track Modifications in Important System Files (check-files)
  5. Synchronizing Two Subversion Repositories (svn-switch)
  6. Working Locally With a Remote Subversion Repository (svn-sync)

Copying

ServerTools, is a collection of some small server tools/scripts. Copyright Dashamir Hoxha.

They are free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

They are distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with ServerTools; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

PHP Looking Glass (phplg)

phplg is a PHP Looking Glass for CISCO Routers. Not too many looking glasses written in PHP can be found around, and in general this one is a very simple/light implementation which can be easily modified.

Copyright (c) 2000, 2001, 2002 
Gabriella Paolini - gabriella.paolini@garr.it 
Personal Home Page: www.gabit.com gabi@gabit.com   
Copyright (c) 2004 Dashamir Hoxha, dhoxha@inima.al

Uploading Files (upload)

This tool can be used to upload files in a web server. It can be used by more than one web application, based on PHP or not, and which can be in the same webserver as upload or in another server. It can be called by using something like this in the HTML of the page:

<form name="upload" method="post" enctype="multipart/form-data" action="http://127.0.0.1/upload/upload_file.php" target="upload_message"> File: <input type="file" name="file" size="60" /><br/> Folder: <input type="text" name="folder" value="pics/" /><br/> <input type="button" class="button" value="Upload" onclick="upload_file()" /> <input type="hidden" name="url" /> </form>

Also, include something like this in the head of the page as well:

<script language="javascript" src="http://127.0.0.1/upload/upload.js"></script> <link rel="stylesheet" type="text/css" href="http://127.0.0.1/upload/upload.css" />

Make any neccessary modifications in upload_file.php as well. It uses wrapper (which is compiled from wrapper.c). The owner of wrapper must be root and it must have the set_uid bit set (# chmod +s wrapper). This is done so that upload_file.php (which is called by apache) can write the uploaded files in the destination directory. However it can create security problems and other solutions can be more prefered. An alternative solution could be to give to apache write permission to the destination directories, and not to use wrapper at all.

Track Modifications in Important System Files (check-files)

These scripts are used to monitor a set of files for changes and to email the changes automatically to the admin. These monitored files are usually configuration files, but they can be anything else.

The idea is to copy them in a directory and import this directory in a Subversion repository. Then copy them periodically and commit in the repository. In case that there are any changes, the svn repository is configured to send these changes by email to the admin.

First make sure that files.txt has a list of the files that will be monitored. It should contain one file per line, with the absolute path of the file. It can also contain directories, in this case all the files of the directory will be monitored recursivly.

Next run init.sh. It will create the directory files/ where all the files will be copied, then will create a svn repository and import them in it, then will checkout a working copy from the repository and will configure the repository for automatic email notification on commit.

The script check.sh will copy the files again (only those that have changed) and will commit the changes. If there are any changes, then post-commit will be called, which uses commit-email.pl to send the changes to a certain email address.

check.sh can be called periodically by a cron job. E.g. to run it daily, create the script /etc/cron.daily/check-files.sh with this content:

#!/bin/bash
### check configuration files
/path/check-files/check.sh

Synchronizing Two Subversion Repositories (svn-switch)

I have a project at SourceForge, but I want to modify it locally, and I want to commit only when I am satisfied with the chages. Meanwhile I want also to have the benefits of version control when working locally (for the small modifications that I make).

This script is used to solve this problem. It synchronizes a working copy with two (or more) subversion repositories. The idea is to backup the .svn directories that are connected to one repository and to restore the ones that are connected to another.

It can be used like this:

  1. Checkout a working copy from the main repository (e.g. from SF).
  2. Copy the directory svn-switch to this directory and edit switch-state so that current_repo is set properly.
  3. Run svn-switch/switch-to.sh local. This will get all the directories named .svn and will make an archive file (tar) with them, which is stored in svn-switch/. Then it will try to restore the .svn dirs of the local repository, but none will be found and some errors will be displayed; ignore them.
  4. Create a local svn repository, import the working copy in it, and checkout a working copy from the local repository.
  5. Now run svn-switch/switch-to.sh sf. It will get the .svn directories of the local repository and restore the .svn directories of the remote repository.
  6. Now everything is set up and svn-switch/switch-to.sh can be used to switch the working copy from one repository to the other, allowing the working copy to be synchronized with both the repositories.
This working copy which is set up this way works as a pipe for transmiting the changes from one SVN repository to another, but without saving the history of the changes.

Working Locally With a Remote Subversion Repository (svn-sync)

These scripts are used to syncronize svn repositories. The case in which I use them is like this:

I make a backup of the svn repositories of the projects at SF. I use this backup svn repository locally to checkout, modify and commit the projects. Then I use the script dump.sh to dump the revisions that were created locally. Finally, I use load.sh to commit these revisions to the SF repository.

The file config.sh has the path of the backup repository directory (which contains the unmodified backup from the SF repository of the projects), the working repository path (which is a copy of the backup that is modified locally), and the main repository path (from which the backup is made and to which the local revisions will be commited).

Note: Since the command svnadmin cannot be used by the members of SF, the commit of the local revisions to the SF repositories can be done by the migration tool (without checking "replace repository").