If you setup wordpress blog, you noticed if you click on URL’s in comments, the URL will open in same window. This is default behavior of WordPress and unfortunately most WordPress don’t support to change this behavior. This situation could annoy for many bloggers as they don’t like the site visitor leave their site for comment author site.
Follow steps below to setup to open comment author URL in new web browser window:
PHP is an opensource server side scripting language and it is a widely used. The Apache web server provides access to files and content over HTTP OR HTTPS protocol. A misconfigured server side scripting language can create all sorts of problems. So, PHP should be used carefully. Here are twenty five php security best practices for sysadmins secure PHP configuration.
Sample Tips for PHP Security
DocumentRoot: /var/www/html
Default Web server: Apache ( you can use Lighttpd or Nginx instead of Apache)
Our sample php security config file: /etc/php.d/security.ini (you need to create this file using a text editor)
Operating systems: RHEL / CentOS / Fedora Linux (the instructions should work with any other Linux distributions such as Debian / Ubuntu or other Unix like operating systems such as OpenBSD/FreeBSD/HP-UX).
Default php server TCP/UDP ports: none
Most of the actions listed in this post are written with the assumption that they will be executed by the root user running the bash or any other modern shell: $ php -v
Sample outputs:
PHP 5.3.3 (cli) (built: Oct 24 2011 08:35:41)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
For demonstration purpose I’m going to use the following operating system: $ cat /etc/redhat-release
Sample outputs:
Red Hat Enterprise Linux Server release 6.1 (Santiago)
1: Know Your Enemy
PHP based apps can face the different types of attacks. I have seen the following types of attacks:
XSS - Cross-site scripting is a vulnerability in php web applications which attackers may exploit to steal users’ information. You can configure Apache and write secure code (validating all user input) to avoid xss attacks.
SQL injection - It is a vulnerability in the database layer of an php application. When user input is incorrectly filtered any SQL statements can be executed by the application. You can configure Apache and write secure code (validating and escaping all user input) to avoid SQL injection attacks. A common practice in PHP is to escape parameters using the function called mysql_real_escape_string() before sending the SQL query.
Spoofing
File uploads – It allows your visitor to place files on your server. This can result into to delete your files, database, get user details and much more. You can disable file uploads using php or write secure code (like validate and only allow image file type such as png or gif).
Including local and remote files – An attacker can open files from remote server and execute any PHP code. This allows them to upload file, delete file and install backdoors. You can configure php to disable remote file execution.
eval() - Evaluate a string as PHP code. This is often used by an attacker to hide their code and tools on server itself. You can configure php to disable eval().
Sea-surf Attack (Cross-site request forgery – CSRF) – This attack forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.
2: Find Built-in PHP Modules
To see the set of compiled-in PHP modules type the following command, enter: # php -m
Sample outputs:
[PHP Modules]
apc
bcmath
bz2
calendar
Core
ctype
curl
date
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
imap
json
libxml
mbstring
memcache
mysql
mysqli
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
readline
Reflection
session
shmop
SimpleXML
sockets
SPL
sqlite3
standard
suhosin
tokenizer
wddx
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib
[Zend Modules]
Suhosin
I recommends that you use PHP with a reduced modules for performance and security. For example, you can disable sqlite3 module by deleting (removing) file , OR renaming (moving) a file /etc/php.d/sqlite3.ini as follows: # rm /etc/php.d/sqlite3.ini
OR # mv /etc/php.d/sqlite3.ini /etc/php.d/sqlite3.disable
Other compiled-in modules can only be removed by reinstallating (reconfigure or rebuild php rpms) PHP with a reduced configuration. You can download php source code and compile it as follows by with GD, fastcgi, and, MySQL support:
To restrict PHP information leakage set expose_php to Off. Edit /etc/php.d/secutity.ini and set the following directive:
expose_php=Off
This option disabled to the world that PHP is installed on the server, which includes the PHP version within the HTTP header (e.g., X-Powered-By: PHP/5.3.3). The PHP logo guids are also exposed, thus appending them to the URL of a PHP enabled site will display the appropriate logo. $ curl -I http://www.cyberciti.biz/index.php
Sample outputs:
Your PHP supports “Dynamic Extensions”. By default, RHEL loads all the extension modules found in /etc/php.d/ directory. To enable or disable a particular module, just find the configuration file in /etc/php.d/ directory and comment the module name. You can also rename or delete module configuration file. For best PHP performance and security, you should only enable the extensions your webapps requires. To disable gd extension, type the following commands: # cd /etc/php.d/
# mv gd.{ini,disable}
# /sbin/service httpd restart
To enable module gd, enter: # mv gd.{disable,ini}
# /sbin/service httpd restart
5: Log All PHP Errors
Do not expose PHP error messages to all site visitors. Edit /etc/php.d/security.ini and set the following directive:
Turn on or off HTTP file uploads (disallow uploading unless necessary). Edit /etc/php.d/security.ini and set the following directive:
file_uploads=Off
If users of your application need to upload files, turn this feature on by setting maximum allowed size for uploaded files:
file_uploads=On
# user can only upload upto 1MB
upload_max_filesize=1M
7: Turn Off Remote Code Execution
The allow_url_fopen option allows PHP’s file functions such as file_get_contents() and the include / require statements, can retrieve data from remote locations, like an FTP or HTTP web site. Programmers frequently forget this and don’t do proper input filtering when passing user-provided data to these functions, opening them up to code injection vulnerabilities. A large number of code injection vulnerabilities reported in PHP-based web applications are caused by the combination of enabling allow_url_fopen and bad input filtering. This option should be disabled. Edit /etc/php.d/security.ini and set the following directive:
allow_url_fopen=Off
I also recommend to disable allow_url_include for security reasons:
allow_url_include=Off
8: Enable SQL Safe Mode
Turn on or off SQL safe mode. Edit /etc/php.d/security.ini and set the following directive:
sql.safe_mode=On
If turned On, mysql_connect() and mysql_pconnect() ignore any arguments passed to them. Please note that you may have to make some changes to your code. Third party and open source application such as WordPress, and others may not work at all when sql.safe_mode set it to On. I also recommend that you turn off magic_quotes_gpc for all php 5.3.x installations:
magic_quotes_gpc=Off
9: Control POST Size
The HTTP POST request method is used when the client (browser or user) needs to send data to the Apache web server as part of the request, such as when uploading a file or submitting a completed form. This can be abused or can be used to crash server. Edit /etc/php.d/security.ini and set the following directive:
post_max_size=1K
The 1K sets max size of post data allowed by php apps. This setting also affects file upload. To upload large files, this value must be larger than upload_max_filesize. I also suggest that you limit available methods using Apache web server. Edit httpd.conf and set the following directive for DocumentRoot /var/www/html:
<Directory /var/www/html>
<LimitExcept GET POST>
Order allow,deny
</LimitExcept>
# Add rest of the config here...
</Directory>
10: Resource Control
You can set maximum execution time of each php script, in seconds. Another recommend option is to set maximum amount of time each script may spend parsing request data and maximum amount of memory a script may consume. Edit /etc/php.d/security.ini and set the following directives:
# set in seconds
max_execution_time = 30
max_input_time = 30
memory_limit = 40M
11: Install Suhosin Advanced Protection System for PHP
Suhosin is an advanced protection system for PHP installations. It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. Suhosin comes in two independent parts, that can be used separately or in combination. The first part is a small patch against the PHP core, that implements a few low-level protections against bufferoverflows or format string vulnerabilities and the second part is a powerful PHP extension that implements all the other protections.
PHP has a lot of functions which can be used to crack your server if not used properly. You can set list of functions in /etc/php.d/security.ini using disable_functions directive:
PHP can be run using FastCGI or cgi. The configuration directive cgi.force_redirect prevents anyone from calling PHP directly with a URL like http://www.cyberciti.biz/cgi-bin/php/hackerdir/backdoor.php. Turn on cgi.force_redirect for security reasons. Edit /etc/php.d/security.ini and set the following directive:
cgi.force_redirect=On
14 PHP User and Group ID
PHP can be run as server. mod_fastcgi is a cgi-module for Apache web server. It can connect to php server. You need to make sure php run as non-root user. If PHP is executing as a CGI, look at a method of executing CGIs as a non-privileged user like Apache’s suEXEC ormod_suPHP. In this example, php-cgi is running as phpcgi user: # ps aux | grep php-cgi
Sample outputs:
You can use tool such as spawn-fcgi to start php server as phpcgi user (first, add phpcgi user to the system): # spawn-fcgi -a 127.0.0.1 -p 9000 -u phpcgi -g phpcgi -f /usr/bin/php-cgi
You can configure Apache, Lighttpd, and Nginx web server to use php running on port 9000 at 127.0.0.1 IP address.
NOTE: If you’re using the Apache module, use Apache users and group to run php.
15 Limit PHP Access To File System
The open_basedir directive set the directories from which PHP is allowed to access files using functions like fopen(), and others. If a file is outside of the paths defined by open_basdir, PHP will refuse to open it. You cannot use a symbolic link as a workaround. For example only allow access to /var/www/html directory and not to /var/www, or /tmp:
open_basedir="/var/www/html/"
; Multiple dirs can be set as follows
; open_basedir="/home/httpd/vhost/cyberciti.biz/html/:/home/httpd/vhost/nixcraft.com/html/:/home/httpd/vhost/theos.in/html/"
16 Session Path
Session support in PHP consists of a way to preserve certain data across subsequent accesses. This enables you to build more customized applications and increase the appeal of your web site. This path is defined in /etc/php.ini file and all data related to a particular session will be stored in a file in the directory specified by the session.save_path option. The default is as follows under RHEL/CentOS/Fedora Linux:
session.save_path="/var/lib/php/session"
; Set the temporary directory used for storing files when doing file upload
upload_tmp_dir="/var/lib/php/session"
Make sure path is outside /var/www/html and not readable or writeable by any other system users: # ls -Z /var/lib/php/
Sample outputs:
Note: Check php.net for the most recent release for source code installations.
18: Restrict File and Directory Access
Make sure you run Apache as a non-root user such as Apache or www. All files and directory should be owned by root user under /var/www/html: # chown -R root:root /var/www/html/
Make sure file permissions are set to 0444 under /var/www/html/: # chmod -R 0444 /var/www/html/
Make sure all directories permissions are set to 0445 under /var/www/html/: # find /var/www/html/ -type d -print0 | xargs -0 -I {} chmod 0445 {}
Make sure httpd.conf has the following directives for restrictive configuration:
<Directory / >
Options None
AllowOverride None
Order allow,deny
</Directory>
You should only grant access when required. Some web applications such as wordpress and others requires caching directories. You need to grant write access to those directroies: # chmod a+w /var/www/html/blog/wp-content/cache
### block access to all ###
# echo 'deny from all' > /var/www/html/blog/wp-content/cache/.htaccess
19: Write Protect Apache, PHP, and, MySQL Configuration Files
Use the chattr command to write protect files: # chattr +i /etc/php.ini
# chattr +i /etc/php.d/*
# chattr +i /etc/my.ini
# chattr +i /etc/httpd/conf/httpd.conf
# chattr +i /etc/
#20: Use Linux Security Extensions (such as SELinux)
Linux comes with various security patches which can be used to guard against misconfigured or compromised programs. If possible use SELinux and other Linux security extensions to enforce limitations on network and other programs. For example, SELinux provides a variety of security policies for Linux kernel and Apache web server. To list all Apache SELinux protection variables, enter: # getsebool -a | grep httpd
Sample outputs:
allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> on
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_read_user_content --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_tmp_exec --> off
httpd_tty_comm --> on
httpd_unified --> on
httpd_use_cifs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off
To disable cgi support, enter: # setsebool -P httpd_enable_cgi off
See Red Hat SELinux guide for more information.
## A few Examples ##
# Do not allow to open files in /etc/
SecFilter /etc/
# Stop SQL injection
SecFilter "delete[[:space:]]+from"
SecFilter "select.+from"
22 Run Apache / PHP In a Chroot Jail If Possible
Putting PHP and/or Apache in a chroot jail minimizes the damage done by a potential break-in by isolating the web server to a small section of the filesystem. You can use traditional chroot kind of setup with Apache. If possible use FreeBSD jails, XEN, KVM, or OpenVZ virtualizationwhich uses the concept of containers.
23 Use Firewall To Restrict Outgoing Connections
The attacker will download file locally on your web-server using tools such as wget. Use iptables to block outgoing connections from Apache user. The ipt_owner module attempts to match various characteristics of the packet creator, for locally generated packets. It is only valid in the OUTPUT chain. In this example, allow vivek user to connect outside using port 80 (useful for RHN or centos repo access):
/sbin/iptables -A OUTPUT -o eth0 -m owner --uid-owner vivek -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
Here is another example that blocks all outgoing connections from apache user except to our own smtp server, and spam validation API service:
# ....
/sbin/iptables --new-chain apache_user
/sbin/iptables --append OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables --append OUTPUT -m owner --uid-owner apache -j apache_user
# allow apache user to connec to our smtp server
/sbin/iptables --append apache_user -p tcp --syn -d 192.168.1.100 --dport 25 -j RETURN
# Allow apache user to connec to api server for spam validation
/sbin/iptables --append apache_user -p tcp --syn -d 66.135.58.62 --dport 80 -j RETURN
/sbin/iptables --append apache_user -p tcp --syn -d 66.135.58.61 --dport 80 -j RETURN
/sbin/iptables --append apache_user -p tcp --syn -d 72.233.69.89 --dport 80 -j RETURN
/sbin/iptables --append apache_user -p tcp --syn -d 72.233.69.88 --dport 80 -j RETURN
#########################
## Add more rules here ##
#########################
# No editing below
# Drop everything for apache outgoing connection
/sbin/iptables --append apache_user -j REJECT
24 Watch Your Logs & Auditing
Check the apache log file: # tail -f /var/log/httpd/error_log
# grep 'login.php' /var/log/httpd/error_log
# egrep -i "denied|error|warn" /var/log/httpd/error_log
Check the php log file: # tail -f /var/log/httpd/php_scripts_error.log
# grep "...etc/passwd" /var/log/httpd/php_scripts_error.log
Log files will give you some understanding of what attacks is thrown against the server and allow you to check if the necessary level of security is present or not. The auditd service is provided for system auditing. Turn it on to audit service SELinux events, authetication events, file modifications, account modification and so on. I also recommend using standard “Linux System Monitoring Tools” for monitoring your web-server.
25 Run Service Per System or VM Instance
For large installations it is recommended that you run static and dynamic content from different servers.
You run different network services on separate servers or VM instance. This limits the number of other services that can be compromised. For example, if an attacker able to successfully exploit a software such as Apache flow, he / she will get an access to entire server including other services such as MySQL, e-mail server and so on. But, in the above example content are served as follows
static.lan.cyberciti.biz - Lighttpd or nginx for static assets such as js/css/images.
phpcgi1.lan.cyberciti.biz and phpcgi2.lan.cyberciti.biz - Apache server with php used for generating dynamic content.
mysql1.lan.cyberciti.biz - Database server.
mcache1.lan.cyberciti.biz - Memcached server is very fast caching system for MySQL. It uses libevent or epoll (Linux runtime) to scale to any number of open connections and uses non-blocking network I/O.
LB01 - It is a nginx web and reverse proxy server. Nginx used in front of Apache Web servers. All connections coming from the Internet addressed to one of the Web servers are routed through the nginx proxy server, which may either deal with the request itself or pass the request wholly or partially to the main web servers.
PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to.
You can use PHPIDS to detect malicious users, and log any attacks detected for later review. Please note that I’ve personally not used this tool.
PhpSecInfo provides an equivalent to the phpinfo() function that reports security information about the PHP environment, and offers suggestions for improvement. It is not a replacement for secure development techniques, and does not do any kind of code or app auditing, but can be a useful tool in a multilayered security approach.
You may come across php scripts or so called common backdoors such as c99, c99madshell, r57 and so on. A backdoor php script is nothing but a hidden script for bypassing all authentication and access your server on demand. It is installed by an attackers to access your server while attempting to remain undetected. Typically a PHP (or any other CGI script) script by mistake allows inclusion of code exploiting vulnerabilities in the web browser. An attacker can use such exploiting vulnerabilities to upload backdoor shells which can give him or her a number of capabilities such as:
Download files
Upload files
Install rootkits
Set a spam mail servers / relay server
Set a proxy server to hide tracks
Take control of server
Take control of database server
Steal all information
Open TCP / UDP ports and much more
Tip: How Do I Search PHP Backdoors?
Use Unix / Linux grep command to search c99 or r57 shell: # grep -iR 'c99' /var/www/html/
# grep -iR 'r57' /var/www/html/
# find /var/www/html/ -name \*.php -type f -print0 | xargs -0 grep c99
# grep -RPn "(passthru|shell_exec|system|base64_decode|fopen|fclose|eval)" /var/www/html/
Conclusion
Your PHP based server is now properly harden and ready to show dynamic webpages. However, vulnerabilities are caused mostly by not following best practice programming rules. You should be consulted further resources for your web applications security needs especially php programming which is beyond the scope of sys admin work.
PHP Security Guide: This guide aims to familiarise you with some of the basic concepts of online security and teach you how to write more secure PHP scripts. It’s aimed squarely at beginners, but I hope that it still has something to offer more advanced users.
Essential PHP Security (kindle edition): A book about web application security written specifically for PHP developers. It covers 30 of the most common and dangerous exploits as well as simple and effective safeguards that protect your PHP applications.
SQL Injection Attacks and Defense This book covers sql injection and web-related attacks. It explains SQL injection. How to find, confirm, and automate SQL injection discovery. It has tips and tricks for finding SQL injection within the code. You can create exploits using SQL injection and design to avoid the dangers of these attacks.
The Subversion for Windows HOWTO describes from a beginner’s perspective, how to install the Subversion server with Apache on a Windows system, and get it running. This how to describes how to use the Apache 2.2 server as the network server component of the Subversion.
This guide is verified on Windows XP, Windows Server 2000 / 2003 and Windows 7. The same point is valid, if you choose to use Apache 2.0 out of any reason – i do not know at the moment.
I will describe all topics that include the installation, basic configuration and setting up backup. It will provide working examples of configuration, ready for you to modify and use.
2. Installation
This chapter describes the process of installation, beginning with the OS installation, continuing with Subversion server installation and ending with Apache 2.2 server installation. You need to install and configure Subversion and Apache 2.2 server as local Administrator on your system.
2.1. Setting up the OS
Since this isn’t a Windows HOWTO, this chapter will be rather short, and answer a few simple questions that I had before I began. The two OS related questions that I was asking myself before starting with the OS installation were:
Does the Subversion server work with Windows 7 and all the patches?
Does the server work on DHCP enabled interface? [some apps don't, you know]
The answer is YES. Install the Windows 7 and all the latest service packs and patches however don’t forget to open the HTTP (80)/ HTTPS(443) (or whatever you setup in your Apache web server) port in firewall to access SVN.
2.2. Installing Subversion
You can download latest release of subversion following this URL:
This documentation describes “Subversion version 1.5.6″, (Setup-Subversion-1.5.6.msi).
Follow setup wizard instructions to complete Subversion installation. The default directory is “C:\Program Files\Subversion” and below is a list of directories the installation creates:
C:\Program Files\Subversion\bin
Contains all the binaries like svn.exe, svnadmin.exe and svnlook.exe. And Contains the Apache 2.2 plug-in modules mod_authz_svn.so and mod_dav_svn.so .
C:\Program Files\Subversion\iconv
C:\Program Files\Subversion\share
C:\Program Files\Subversion\licences
The C:\Program Files\Subversion\bin is added to the path.
And that’s about all there is to the installation.
2.3. Installing Apache 2.2
The Apache 2.2 server for Windows installation package can be downloaded from the Apache.org server, at the following URL:
This article describes this “apache_2.2.14-win32-x86-openssl-0.9.8k.msi” version of Apache.
Follow setup wizard instructions to install Apache. During installation process you need to:
Select the Apache binding
Enter your domain name
Server name
Administrator’s e-mail address and
The port the server will be listening on. You can override default values. For dedicated a subversion server, I suggest you leave it running on port 80. You can change this port later.
You can select typical or custom install. Selecting typical install lets you choose the destination directory.
At the end of installation process, installer may prompt to restart your server. I recommend you to restart server to finish installation.
3. Configuration
We will discuss to configure the Subversion system and Apache Web Server to make it available over the network/ internet.
3.1. Configuring Subversion
The Subversion stores the content in repositories. You need at least one repository to store all your data into, or may setup multiple repositories, one for each project. This HOWTO will assume multiple repositories are used. We will call these projects project1 and project2.
Let’s create a directory for all our projects, and then a subdirectory for each of the projects, e.g.:
C:\Repositories\project1
C:\Repositories\project2
These are just directories to hold our repositories, now need to create the repositories themselves, using the “svnadmin” utility:
svnadmin create C:\Repositories\project1
svnadmin create C:\Repositories\project2
Note: Make sure to create all repositories on your local disks [FiberChannel is treated as a local disk]. Failing to do so, may result in repository corruption.
Each repository is stored in a Berkeley DB database, which can be configured in many different ways, but the default configuration works, and for a beginner, I found no reason to change anything.
To make repositories available to your development teams, you need to setup Apache Web Server.
3.2. Configuring Apache 2.2 server
As the Apache server will only be a front end for the Subversion system. I suggest storing all Subversion specific files in separate directory.
C:\etc
Note: The Apache server require writing all the directories using forward slash as the separator e.g. “C:/Program Files/Apache Software foundation/Apache2.2″.
Step 1:
Copy the files mod_authz_svn.so and mod_dav_svn.so from “C:\Program Files\Subversion\httpd” into “C:\Program Files\Apache Software foundation\Apache2.2\modules”.
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride None
#
# Controls who can get stuff from this server.
#
Order allow,deny
Allow from 10.0.1
</Directory>
This allows access from all computers in the address range 10.0.1.1 – 10.0.1.254 .
At the end of the file, include a Subversion configuration file. We will create this file in one of the next steps.
Include c:/etc/subversion.conf
Place the “subversion.conf” file in the before mentioned etc directory.
Step 3:
To restrict anonymous access to repositories and protect projects/ repositories or setup permissions for specific users on a projects/ repositories, we need to create a password file for authentication.
Subversion should only accessible to authenticated users, e.g. you need to provide credentials to access Subversion. You need to create developer accounts with passwords.
Let us name our developers Harry and Sally. Since we have two projects, we’ll have a somewhat bigger development department, adding Ross and Rachel to our list of employees.
cd C:\Program Files\Apache Software Foundation\Apache2.2\bin
htpasswd -cm C:\etc\svn-auth-file harry
C:\Program Files\Apache Software Foundation\Apache2.2\bin>htpasswd -cm C:\etc\svn-auth-file harry
When using the command for the first time, add the -c option. This creates the file named “C:\etc\svn-auth-file”. The -m option instructs the htpasswd utility to use MD5 algorithm to encrypt the passwords.
Step 4:
Now we can authenticate our users, we must configure the access rights to our repositories. To setup access rights, we need to create another file in our etc directory.
# team1 group has a read/write access to project1 repository
# all subdirectories
# all others have read access only
#
[project1:/]
@team1 = rw
* = r
#
# project2 repository, only harry and sally have read-write access to project2
#
[project2:/]
harry = rw
sally = rw
* = r
#
# ross is helping with the time zone part of the project2
#
[project2:/timezone]
harry = rw
sally = rw
ross = rw
* = r
The groups section can be used to define groups of users. For repository project1, only users from the group team1 have read/write access. All other users have read only access.
It is possible to define access for the entire repository, or for specific directory within repository.
Step 5:
In the end it is time to link the Apache server with the Subversion. This is done using the C:\etc\subversion.conf file:
<Location /project1>
DAV svn
SVNPath C:/Repositories/project1
AuthType Basic
AuthName "Subversion Project1 repository"
AuthUserFile c:/etc/svn-auth-file
Require valid-user
AuthzSVNAccessFile c:/etc/svn-acl
</Location>
<Location /project2>
DAV svn
SVNPath C:/Repositories/project2
AuthType Basic
AuthName "Subversion Project2 repository"
AuthUserFile c:/etc/svn-auth-file
Require valid-user
AuthzSVNAccessFile c:/etc/svn-acl
</Location>
The developers can access the “C:\Repositories\project1″ repository at the “http://subversion/project1” (http://localhost/project1/) URL. The access is only available to a valid user, and a basic HTTP authentication is used. The Apache server can read the valid user names and passwords from the “C:\etc\svn-auth-file” file. The “c:\etc\svn-acl” file defines the access rights to the repository.
Don’t forget to restart the Apache server for the configuration changes to take effect.
Conclusion
We have created the Subversion repositories, and configured an Apache server to access over network. User names and passwords have to be used to access the repositories, and different levels of access are given to different users. Congratulates, Subversion is configured successfully.
4. Backup
Having a central Version control system without a backup is a bad practice. In this section we need to create a system utility that will run on scheduled interval / manually, and dump all the changes made to a repository in a new file. Moving data to permanent storage i.e. DVD-ROM disk is not included in this article.
4.1. What to back up?
No doubt, these are our repositories to backup that we created earlier and used to store our data. In our article the dumps will stored in directory named “c:\backup\dumps”, you can select dump location of your choice. I also recommend backing up the c:\etc directory. I keep the latest version of the Apache “httpd.conf” file in it. This makes a total of 2 directories. Everything else can be downloaded from the Internet, if the worst happens.
It’s recommended to turn on the compression on the backup folder, to preserve space.
4.2. Creating a repository dump
Since writing programs is what I do, I have decided to use VB Script for the backup procedure. The script basically has a subroutine [CreateDump] that gets the last known revision number for a given repository, compares it to the current revision, and if necessary, dumps the most recent changes into a file.
To break this down further, the subroutine has five parameters:
A name of the log file
A name of the file containing the last know revision
A command string for getting the youngest revision of the defined repository
The repository that is to be dumped
A fragment of the dump file name
In the example, for the Project1 the subroutine opens a log file, and compares the last know revision number [i.e. stored in the file c:\etc\proj1-last] to the youngest revision number for that repository. For example, if the last known revision number for repository “C:\Repositories\project1″ is 4712 and the youngest revision is 4738, the subroutine executes the following command:
The dump is saved into a file “c:\backup\dumps\proj1-4712-4738.dmp”.
If the file “c:\etc\proj1-last” does not exist, the last known revision number is assumed to be 0 and the option –incremental is omitted from the dump command.
The example below creates backup files for two repositories. It uses two separate log files, but the script can easily be modified to only use one. But, it must use different lastFileName for each repository. It can be scheduled to run at your convenience. I run it once a day.
' Open the destination file and execute the dump command
Set objDumpFile = objFSO.OpenTextFile( dumpFileName, ForWriting, True )
Set objExecDump = WshShell.Exec( dumpCommand )
' Read the dump output and write it to the file
Do While True
If Not objExecDump.StdOut.AtEndOfStream Then
input = objExecDump.StdOut.Read( 1 )
objDumpFile.Write input
Else
Exit Do
End If
Loop
objDumpFile.Close
' Write the latest revision into the file
Set objTextFile = objFSO.OpenTextFile( lastFileName, ForWriting, True )
objTextFile.Write youngest
objTextFile.Close
' Close the log file and exit
objLogFile.WriteLine Now & " Script done"
objLogFile.Close
End Sub
5. Upgrade
If you need to upgrade the Apache server, please follow below sections.
5.1. Upgrading Apache 2.2 server
Apache upgrade is a bit specific. Upgrade option is not available and you need to uninstall the currently installed version first. There is nothing much to it, just go to the Windows Control Panel \ Add or Remove Programs and select Remove.
Note: Before to proceed to uninstall Apache make sure to back up your latest httpd.conf file in a safe location.
After the un-installation you are left with a couple of folders, namely:
Since Apache installation doesn’t like the fact that files and folder it is trying to create already exists, I suggest you rename the C:\Program Files\Apache Software foundation\Apache2.2 to something original, like C:\Program Files\Apache Software foundation\Apache2.2-old. That way you get to keep all your Apache log files. If you don’t need them you can delete the Apache2.2 folder all together.
Now you are ready to install the new Apache 2.2 server as described in section 2.3. Installing Apache 2.2. After that, all you need to put the old httpd.conf in the C:\Program Files\Apache Software foundation\Apache2.2\conf folder, copy the mod_authz_svn.so and mod_dav_svn.so into the C:\Program Files\Apache Software foundation\Apache2.2\modules folder, and you’re done. You have just successfully upgraded Apache 2.2 server.
5.2. Upgrading Subversion
Before you begin you need to decide whether you will keep your repositories as they are, or reload them from the dump files.
Let’s proceed with decision to reload them from my backups, because of the speedup in repository operations. It now takes much less time to commit, update or simply get file contents at specific revision. But loading from the dump a file takes some time, so if your backup has become too large, you may want keep the current repositories. If you want to keep your current database, this is what you need to do before you upgrade [taken from the Win32 release notes]:
***** IMPORTANT *** Upgrading from 1.1.x to 1.2.x *** IMPORTANT *****
In this release, we've upgraded BerkeleyDB from version 4.2.52 to
4.3.27. If you are currently using Subversion 1.1.x as a server on
Windows with BerkeleyDB, use the following steps to upgrade your
repositories:
-- Make sure nobody is using the repository (stop Apache/svnserve,
restrict access via file://).
-- For each repository, using the old (1.1.x) binaries:
-- Run "svnadmin recover <repos-dir>";
-- Create a backup of the repository;
-- Run "svnadmin list-unused-dblogs <repos-dir>"
and remove the listed files;
-- Delete all the "<repos-dir>\db\__db.00?" files.
-- Upgrade Subversion.
Once again, this is only necessary for repositories based on BDB.
You may also want to change your repositories from BDB to FSFS, or vice versa. In that case you will need to reload your repository from the dump files anyway. So, let’s start with the upgrade process.
Step 1:
First you need to make sure that nobody can access your repositories while you’re doing the upgrade, so stop the Apache server.
Step 2:
Make sure that your last backups contain the latest revision stored in your repositories. You can check your backup names against each repository head revision number by hand
svnlook youngest C:\Repositories\project2
OR you can simply run the backup script:
C:\windows\system32\cscript.exe c:\etc\backup.vbs
This will bring your backups up to date. You may want to transfer them to the tape, burn CD, or whatever you store the backups on.
Step 3 is only needed, if you want to reload your repositories from the dump files. If not, skip it.
Step 3:
If you have enough space on your disk, rename your “C:\Repositories” folder to something else, so you will have a binary backup of your current repositories.
Step 4:
At this point you can run the Subversion installation. The process is described in section 2.2. Installing Subversion with minor difference.
The installation process detects that you are running an Apache 2.2 server and notifies you, that it will stop its services, and restart them after the installation. Also, it offers to copy the mod_authz_svn.so and mod_dav_svn.so to the “C:\Program Files\Apache Software foundation\Apache2.2\modules” folder for you, but there is an error in the current installation of Subversion, which prevents this from happening.
After the installation is complete, check the Apache services, and stop them if they are running.
Steps 5, 6 and 7 only apply, if you have decided to reload your repositories from the dump files. If you have decided to keep your repositories unchanged, you may skip directly to step 8.
Step 5:
Recreate the directories first:
C:\Repositories\project1
C:\Repositories\project2
Step 6:
The repositories themselves; the default storage for the repository has changed from “BerkeleyDB” to “FSFS”, so you need to specify –fs-type bdb explicitly if you want to create a BerkeleyDB repository.
Step 8:
The last thing you need to do is manually copy the mod_authz_svn.so and mod_dav_svn.so files to the C:\Program Files\Apache Software foundation\Apache2.2\modules directory. The location of the files has changed with the version 1.2.0 and the MSI script doesn’t seem to be aware of that either. You can find both files in the C:\Program Files\Subversion\bin directory.
Step 9:
Start the Apache server.
Subversion is now upgraded to version 1.2.0, and if that is what you has decided, your repositories have been reloaded from revision 0 up with all your data, resulting in faster repository operations.
For bloggers who host their own blog or website, it is inevitable that it will have to be moved. First, you might need to move your blog if you are switching your web host. Second, you might also need to ‘move’ your website if you are transferring it to a new domain, new directory, or upgrading / changing your local server.
Use the links below to navigate to the appropriate set of instructions.
Move WordPress to a New Hosting Package
I’m describing easiest way here and there are two main ways to go about it.
Method 1: Use WordPress’ Built-In Import
WordPress features a built-in import to facilitate the process of moving content from one blog to another. And there are only three steps that you need to follow to get you blog up and running.
Create an export file. On your own blog, navigate to ‘Export’ and create a WordPress export file. This is a special XML files which will contain your posts, pages,comments, custom fields, categories, and tags.
Install WordPress on your new host. You will now need to create a working installation of WordPress on your new host. And be sure to upload your entire wp-content directory to the new installation.
Import the WordPress export files. Now, navigate to ‘Import’ on the new installation and upload the export file that you created in step 1. And that’s it! Your website should be completely functional.
Method 2: Work Directly With The Database
Sometimes, due to hosting restrictions, or based on the size of your export file, Method 1 will not work so well. So now, you’ll hear about our preferred method. For this, you will need database access, (often phpMyAdmin,) and a little more technical knowledge.
Create a database dump or database export file. Access your database and download its contents. Sometimes, a web host will have a utility which ‘backs up’ a database without ever having to access the database directly.
Transfer all files. Using FTP download all files from your ‘old’ web host. And then upload them to your new web host. Be sure to update the settings in your wp-config.php file, which holds your database access information.
Import your database. You will now need to access the new database. Once it is set up, import the file that you created in step 1.
The move to a new directory is likely easier than moving to a new domain. Here are the options that we suggest:
Option 1:Move Files
Transfer all files. As in the steps above, transfer all files from the old directory to the new directory. Do not delete any files yet!
Update your WordPress settings. In the WordPress admin area for the ‘old’ directory, go to Settings->General. Update the ‘WordPress address’ and ‘Blog address’ to reflect the change. When you hit save, the blog will no longer be accessible in your old directory.
Update permalinks. Now, navigate to the new directory. You should see the blog up and running. Upload and activate the Update URLs plugin. Go to Settings->Update URLs and enter the appropriate settings to update all of your links. And presto, your website is ready to go.
Clean up. Once you verify that the transfer was successful, you can delete the files in your old WordPress directory.
Option 2: WordPress Import/Export
You can also opt for the WordPress Import/Export file method given above as Method 1. If you choose this method, you will also have to update your permalinks using the Update URLs plugin.
Option 3: Only Change URL
Sometimes, it is not possible to change the physical WordPress directory. In these cases, you can change the url by simply updating WordPress settings. To do this, go to Settings -> General. Here you will find two settings: WordPress Address and Blog Address. By updating only the Blog Address, WordPress will ‘map’ to the new directory. Note: You will need to move the index.php file to the blog address directory.
New Domain
Likewise, there are multiple ways to move to a new domain.
Method 1 – revised (WordPress Import)
To move to a new domain, we suggest Method 1 above. If you have a lot of posts, this may be tricky as the export tool has been known to ‘timeout’. However, you might be able to create multiple export files by creating one file per author. The only modification to method 1 is the step below.
4. Update permalinks. Upload and activate the Update URLs plugin. Go to Settings->Update URLs and enter the appropriate settings to update all of your links.
Method 2 – revised(Database)
Similarly, you can also opt to work directly with the database, as in Method 1. If working with the database, you will have a bit more technical work on your hands. See step 4 below.
4. Update settings with SQL. One you have successfully imported the database, you will need to update some settings to make the website functional. SQL sample queries are listed below.
Sample Query To Update WordPress Settings
UPDATE wp_options SET option_value = replace(option_value, 'http://www.old-url.com', 'http://www.new-url.com') WHERE option_name = 'home' OR option_name = 'siteurl';
Sample Query To Update Permalinks
UPDATE wp_posts SET guid = replace(guid, 'http://www.old-url.com','http://www.new-url.com');
Sample Query to Update Any Links Embedded In Content
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.old-url.com', 'http://www.new-url.com');
Note: Before executing this query make sure to change http://old-url.com with the URL of your old domain/ wordpress instance i.e. “http://ssysadmin.com/worpress” and change http://www.new-url.com to new instance of wordpress/ domain i.e. “http://ssysadmin.com/newwordpress”
Sometimes, you might have omitted the www from your domain when cross-linking posts or referencing images, so you should also run the above query without the ‘www’ for your old domain.
For more information on changing the website url, see
In relation to PHP programming language, MySQL is the old database driver, and MySQLi is the Improved driver. MySQLi takes advantage of the newer features of MySQL 5. Lifted verbatim from the php.net site:
IIS versions before 7.0 did not require <handlers> for AJAX to work.
If you are installing AJAX on new IIS7 servers, you will have to make sure you have the following code in your web.config:
<!--
The system.webServer section is required for running ASP.NET AJAX under Internet
Information Services 7.0. It is not necessary for previous version of IIS.
-->
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules>
<remove name="ScriptModule"/>
<add name="ScriptModule" preCondition="managedHandler" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</modules>
<handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<remove name="ScriptHandlerFactory"/>
<remove name="ScriptHandlerFactoryAppServices"/>
<remove name="ScriptResource"/>
<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add name="ScriptResource" verb="GET,HEAD" path="ScriptResource.axd" preCondition="integratedMode" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</handlers>
</system.webServer>
The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine.
Description: An unhandled exception occurred during the execution of the current web request.
Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InvalidOperationException: The ‘Microsoft.Jet.OLEDB.4.0′
provider is not registered on the local machine.
Solution:
You will get this error on Windows Server 2008 R2 or Windows 7 64 bit. To fix it, switch your Application Pool from Native 64 bit to 32 Bit more under Advanced Settings.
Suggestion:
It is also suggested that you upgrade your application to new ACE OLEDB provider, you can download from here.
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
Config Error
This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".
226: <system.webServer>
227: <handlers>
If you get the error above, you have to make a change in ApplicationHost.config file. To fix this error follow the steps as below:
Open ApplicationHost.config file in notepad This file is located under C:\Windows\System32\inetsrv\config
Search for <location path=”Default Web Site” overrideMode=”Deny”>
Replace with: <location path=”Default Web Site” overrideMode=”Allow”>
Change “Default Web Site” with the name of your website.
NOTE: On 64 bit Windows, if you are using 32 bit editor or File Manager, you will NOT be able to see any files in the config folder. Navigate using Windows Explorer or Notepad in native 64 bit mode.
If you need a domain URL redirection from yourdomain.com to www.testdomain.com or vise versa, you can do something like this:
Place either of these (depending on what you’d like done. And edit to match your domain) inside the <system.webServer></system.webServer> tags in the web.config of the domain.