SWCP Support Wiki - User contributions [en]

Migration to Web Farm 2

2009-04-07T22:23:43Z

Victoria: /* =Where to test */

==Migrating Your Website to the New Southwest Cyberport Webfarm==

===Purpose===
*Describe how to test your current site on the new Webfarm
*Encourage thorough testing of sites moving to the new Southwest Cyberport Webfarm
*List the upgraded software packages
*Provide a few suggestions to avoid common pitfalls.
*Encourage '''thorough''' testing. Really. You won't regret doing it. You will probably regret ''not'' doing it.

===Testing Your Site===
====What to test====
We cannot stress enough the importance of testing your site on the new webfarm. Do not just verify that your home page loads. Here is a partial list of behavior that should receive close scrutiny:
*Form submissions
**Make sure your customers can reach you!
*Dynamic content generated by:
**PHP code
**CGI scripts
**Apache Server Side Includes
**Javascript
*Redirection [http://en.wikipedia.org/wiki/URL_redirection#Purposes (best used sparingly)]:
**.htaccess, PHP, META tags, CGI, Javascript, etc.

Beware any hard-coded links (like <a href="http://www.YourDomain.com/otherfile.html">) - those will go to the current webfarm, rather than the new one.

====Where to test====
In most cases, we want to add the subdomain 'test' so that:
:www.YourDomain.com => your site, via the current webfarm
:test.YourDomain.com => your site, via the new webfarm

*If we control DNS for your domain:
** We have already created the URL ''''test'''.YourDomain.com' - use this URL to test your current site on the new webfarm. Let us know if this URL doesn't work.
** When you're finished testing your site, [mailto:help@swcp.com send us an email] instructing us to fully migrate your site to the new webfarm.
** Test your site again, using 'www.YourDomain.com' rather than the test URL.

*If we do '''not''' control DNS for your domain:
<div style="background-color:#FFF2F2; border:red solid 2px; margin-left:1em">
:Be careful when changing DNS entries for your domain.<br />Invalid DNS entries will make it impossible to reach your site.<br />These steps may not work for domains with multiple subdomains or other non-trivial DNS records
</div>
:* For testing, we have created a URL for you to use that is similar to this:

::'''<code>yourdomain.swcp.com.</code>'''

:* Once you are finished testing, update all relevent '''A''' records to point to 216.184.2.32.

====The files you are testing====
The test virtual points at exactly the same files as your main, live site. You do not need to upload anything. Anything that you want to change can be changed through your normal file upload method (FTP), but ''be aware that this will also change your live site''.

===Hosting Environment Changes===
<table cellpadding=4 border=1>
<tr bgcolor="#cccccc">
<td> </td>
<td><b>PHP Version</b></td>
<td><b>Apache Version</b></td>
<td><b>IP Address</b></td>
</tr>
<tr>
<td bgcolor="#cccccc">Current Webfarm</td>
<td>4.3</td>
<td>1.3</td>
<td>216.184.2.18</td>
</tr>
<tr>
<td bgcolor="#cccccc">New Webfarm</td>
<td>5.2</td>
<td>2.2</td>
<td>216.184.2.32</td>
</tr>
</table>
<br />

====PHP Notes====
*'''Register Globals'''
**Register Globals is now '''disabled''' by default. We can enable it for your site at your request.
**Questions? Please read [http://us.php.net/register_globals PHP.net's description of ''Register Globals.'']
**We strongly encourage our customers using ''Register Globals'' to consider refactoring their code at this time. ''Register Globals'' is deprecated and will be removed from PHP 6.

====Apache Notes====
*'''.htaccess files'''
**Though most .htaccess behavior will not be affected, all sites with .htaccess files should be tested.
**The directive '''<code>+FollowSymLinks</code>''' needs to changed to '''<code>+SymLinksIfOwnerMatch</code>'''
***Read [http://httpd.apache.org/docs/2.2/urlmapping.html#outside Apache.org's description of this directive]

Migration to Web Farm 2

2009-04-07T22:23:20Z

Victoria: /* Testing Your Site */

==Migrating Your Website to the New Southwest Cyberport Webfarm==

===Purpose===
*Describe how to test your current site on the new Webfarm
*Encourage thorough testing of sites moving to the new Southwest Cyberport Webfarm
*List the upgraded software packages
*Provide a few suggestions to avoid common pitfalls.
*Encourage '''thorough''' testing. Really. You won't regret doing it. You will probably regret ''not'' doing it.

===Testing Your Site===
====What to test====
We cannot stress enough the importance of testing your site on the new webfarm. Do not just verify that your home page loads. Here is a partial list of behavior that should receive close scrutiny:
*Form submissions
**Make sure your customers can reach you!
*Dynamic content generated by:
**PHP code
**CGI scripts
**Apache Server Side Includes
**Javascript
*Redirection [http://en.wikipedia.org/wiki/URL_redirection#Purposes (best used sparingly)]:
**.htaccess, PHP, META tags, CGI, Javascript, etc.

Beware any hard-coded links (like <a href="http://www.YourDomain.com/otherfile.html">) - those will go to the current webfarm, rather than the new one.

====Where to test===
In most cases, we want to add the subdomain 'test' so that:
:www.YourDomain.com => your site, via the current webfarm
:test.YourDomain.com => your site, via the new webfarm

*If we control DNS for your domain:
** We have already created the URL ''''test'''.YourDomain.com' - use this URL to test your current site on the new webfarm. Let us know if this URL doesn't work.
** When you're finished testing your site, [mailto:help@swcp.com send us an email] instructing us to fully migrate your site to the new webfarm.
** Test your site again, using 'www.YourDomain.com' rather than the test URL.

*If we do '''not''' control DNS for your domain:
<div style="background-color:#FFF2F2; border:red solid 2px; margin-left:1em">
:Be careful when changing DNS entries for your domain.<br />Invalid DNS entries will make it impossible to reach your site.<br />These steps may not work for domains with multiple subdomains or other non-trivial DNS records
</div>
:* For testing, we have created a URL for you to use that is similar to this:

::'''<code>yourdomain.swcp.com.</code>'''

:* Once you are finished testing, update all relevent '''A''' records to point to 216.184.2.32.

====The files you are testing====
The test virtual points at exactly the same files as your main, live site. You do not need to upload anything. Anything that you want to change can be changed through your normal file upload method (FTP), but ''be aware that this will also change your live site''.

===Hosting Environment Changes===
<table cellpadding=4 border=1>
<tr bgcolor="#cccccc">
<td> </td>
<td><b>PHP Version</b></td>
<td><b>Apache Version</b></td>
<td><b>IP Address</b></td>
</tr>
<tr>
<td bgcolor="#cccccc">Current Webfarm</td>
<td>4.3</td>
<td>1.3</td>
<td>216.184.2.18</td>
</tr>
<tr>
<td bgcolor="#cccccc">New Webfarm</td>
<td>5.2</td>
<td>2.2</td>
<td>216.184.2.32</td>
</tr>
</table>
<br />

====PHP Notes====
*'''Register Globals'''
**Register Globals is now '''disabled''' by default. We can enable it for your site at your request.
**Questions? Please read [http://us.php.net/register_globals PHP.net's description of ''Register Globals.'']
**We strongly encourage our customers using ''Register Globals'' to consider refactoring their code at this time. ''Register Globals'' is deprecated and will be removed from PHP 6.

====Apache Notes====
*'''.htaccess files'''
**Though most .htaccess behavior will not be affected, all sites with .htaccess files should be tested.
**The directive '''<code>+FollowSymLinks</code>''' needs to changed to '''<code>+SymLinksIfOwnerMatch</code>'''
***Read [http://httpd.apache.org/docs/2.2/urlmapping.html#outside Apache.org's description of this directive]

Migration to Web Farm 2

2009-04-07T22:22:39Z

Victoria: /* Testing Your Site */

==Migrating Your Website to the New Southwest Cyberport Webfarm==

===Purpose===
*Describe how to test your current site on the new Webfarm
*Encourage thorough testing of sites moving to the new Southwest Cyberport Webfarm
*List the upgraded software packages
*Provide a few suggestions to avoid common pitfalls.
*Encourage '''thorough''' testing. Really. You won't regret doing it. You will probably regret ''not'' doing it.

===Testing Your Site===
====What to test====
We cannot stress enough the importance of testing your site on the new webfarm. Do not just verify that your home page loads. Here is a partial list of behavior that should receive close scrutiny:
*Form submissions
**Make sure your customers can reach you!
*Dynamic content generated by:
**PHP code
**CGI scripts
**Apache Server Side Includes
**Javascript
*Redirection [http://en.wikipedia.org/wiki/URL_redirection#Purposes (best used sparingly)]:
**.htaccess, PHP, META tags, CGI, Javascript, etc.

Beware any hard-coded links (like &lta href="http://www.YourDomain.com/otherfile.html"&gt) - those will go to the current webfarm, rather than the new one.

====Where to test===
In most cases, we want to add the subdomain 'test' so that:
:www.YourDomain.com => your site, via the current webfarm
:test.YourDomain.com => your site, via the new webfarm

*If we control DNS for your domain:
** We have already created the URL ''''test'''.YourDomain.com' - use this URL to test your current site on the new webfarm. Let us know if this URL doesn't work.
** When you're finished testing your site, [mailto:help@swcp.com send us an email] instructing us to fully migrate your site to the new webfarm.
** Test your site again, using 'www.YourDomain.com' rather than the test URL.

*If we do '''not''' control DNS for your domain:
<div style="background-color:#FFF2F2; border:red solid 2px; margin-left:1em">
:Be careful when changing DNS entries for your domain.<br />Invalid DNS entries will make it impossible to reach your site.<br />These steps may not work for domains with multiple subdomains or other non-trivial DNS records
</div>
:* For testing, we have created a URL for you to use that is similar to this:

::'''<code>yourdomain.swcp.com.</code>'''

:* Once you are finished testing, update all relevent '''A''' records to point to 216.184.2.32.

====The files you are testing====
The test virtual points at exactly the same files as your main, live site. You do not need to upload anything. Anything that you want to change can be changed through your normal file upload method (FTP), but ''be aware that this will also change your live site''.

===Hosting Environment Changes===
<table cellpadding=4 border=1>
<tr bgcolor="#cccccc">
<td> </td>
<td><b>PHP Version</b></td>
<td><b>Apache Version</b></td>
<td><b>IP Address</b></td>
</tr>
<tr>
<td bgcolor="#cccccc">Current Webfarm</td>
<td>4.3</td>
<td>1.3</td>
<td>216.184.2.18</td>
</tr>
<tr>
<td bgcolor="#cccccc">New Webfarm</td>
<td>5.2</td>
<td>2.2</td>
<td>216.184.2.32</td>
</tr>
</table>
<br />

====PHP Notes====
*'''Register Globals'''
**Register Globals is now '''disabled''' by default. We can enable it for your site at your request.
**Questions? Please read [http://us.php.net/register_globals PHP.net's description of ''Register Globals.'']
**We strongly encourage our customers using ''Register Globals'' to consider refactoring their code at this time. ''Register Globals'' is deprecated and will be removed from PHP 6.

====Apache Notes====
*'''.htaccess files'''
**Though most .htaccess behavior will not be affected, all sites with .htaccess files should be tested.
**The directive '''<code>+FollowSymLinks</code>''' needs to changed to '''<code>+SymLinksIfOwnerMatch</code>'''
***Read [http://httpd.apache.org/docs/2.2/urlmapping.html#outside Apache.org's description of this directive]

Server Side Includes

2009-03-06T20:26:19Z

Victoria:

==How to use Server Side Includes (SSI) on your website hosted at SWCP==

SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve
the entire page via a CGI program, or other dynamic technology.

The decision of when to use SSI, and when to have your page entirely generated by some program, is usually a matter of how much of the page is static, and how much needs to be recalculated every time the page is served. SSI is a great way to add small pieces of information, such as the current time. But if a majority of your page is being generated at the time that it is served, you need to look for some other solution.

Some common, easy to use SS directives are:
<pre>
 To display the current date in the page.
 To display the modifcation date of a file.
 Usually used to include something that repeats on many pages, such as a standard hearder or footer.
</pre>
For the SSI to work, the HMTL file must end in .shtml, as in example.shtml.

===CGI===

SSI can also be used to execute an external CGI script and display the output. To use this feature with SWCP web hosting you must do 2 things. First, you must use the "include virtual" syntax.

<pre>

</pre>

Second, you must put the script in your cgi-bin directory, and call it with your script alias, just like you would call a CGI script from a form. For example, user johndoe wants to use SSI to execute the script cutequote.pl. He would put the script in /users/johndoe/public_html/cgi-bin. Then in his web page, he'd use this:
<pre>

</pre>

See also: [[SWCP CGI Scripts]]

Server Side Includes

2009-03-06T20:25:10Z

Victoria: New page: ==How to use Server Side Includes (SSI) on your website hosted at SWCP== SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pag...

For Web Developers

2009-03-06T20:24:36Z

Victoria: /* Sections */

As part of SWCP's interest in Open Source software and easy to use web based applications we're working on making several open source packages easily available, see [[Webapps]] for more information about this. Many common questions are answered in the
[[KB WebApps|Web Apps]] section of our [[Knowledge Base]].

This section of the Wiki will contain more detailed information about web applications, CSS, Web brower issues,
HTML editors, and other web development issues. This is still under development, so bear with us. If you have a
topic you'd like us to cover, send email to help@swcp.com and we'll try to find you some answers.

==Sections==
How web browsing works. ( whose rendering what, when? )

[[Quick Recipes]] ( Short snippets of code for specific tasks )

[[Website Problems]] Things that behave badly.

[[SWCP CGI Scripts]] Scripts available for adding counters, simple forms, etc.

[[Server Side Includes]]

Website Design Tools

Content Management Tools

[[WebApps]] - Tips and tricks for the web applications that SWCP supports (MediaWiki, WordPress, etc.)

Maildrop Syntax Tutorial

2009-01-26T17:27:02Z

Victoria: New page: =An Introduction to Maildrop filtering syntax= SWCP uses Maildrop to handle its anti-spam filtering. However, Maildrop also allows for a lot of other types of filtering, most of which re...

=An Introduction to Maildrop filtering syntax=

SWCP uses Maildrop to handle its anti-spam filtering. However, Maildrop also allows for a lot of other types of filtering, most of which require manually editing .mailfilter files (and reading your email on the server via TWIG, pine, mutt, etc.). This tutorial covers the basics of manually editing a .mailfilter for an assortment of uses.

Additionally, SWCP provides a web interface for our end users to create a user's .mailfilter file, and most of our users use the web interface to do so. '''Manual editing is incompatible with web interface editing'''.

==Getting Started==
If you wish to manually edit your .mailfilter, first log into https://kumo.swcp.com/spam and set the option "Filtering" to No. Wait 15 minutes. You should have a new file called .mailfilter.swcp. From this point you can hand edit the file then rename it to .mailfilter. To keep SWCP or the web interface from mistakenly overwriting your .mailfilter file, be sure to remove the very top line:

# SWCP:MAILFILTER:neal

=Variables=
Variables can be declared as below.

Without Quotes
DEFAULT=/var/mail/sampleuser

With variable substitution
SPAMCAN=/var/spool/mail/spamdrop/$LOGNAME

With quotes
SUPPORT="/users/sampleuser/mail/support"

With quotes and variable substitution
HELP="/users/$LOGNAME/mail/help"

=Logging your filtered email=
I have found that logging filtered email makes troubleshooting much easier.
To make this function operate you'll want to set the logfile variable. Then in
each recipe add a log line with a comment. Here's an example.

logfile "/home/sampleuser/.mailfilter.log"
...

if (/^To:.*sampleuser@swcp.com /)
{
log "Ptrn: sampleuser@swcp.com whitelist"
to "$DEFAULT"
}

Now when this rule is matched and delivers a message your .mailfilter.log will
have a set of lines in it similar to this.

Ptrn: sampleuser@swcp.com whitelist
Date: Wed Apr 23 17:21:44 2003
From: Some Sender <someone@somewhere.com>
Subj: Some Subject
File: /var/spool/mail/sampleuser

As you can see this makes finding an elusive problem somewhat easier. There is one
unfortunate side effect, of course there had to be one :-) Depending on how quickly your
mailserver is getting email you may find that the 'Ptrn:' line and the 'Date: From: Subj:
File:' lines are out of sync. These are difficult problems to solve without modifying the
source to maildrop.

=Filter Contents of the To: Cc: From: or Subject: fields.=
Visit http://www.flounder.net/~mrsam/maildrop/maildropfilter.html for complete regex syntax.

if (/^To:.*sampleuser@swcp.com /)
{
to "$DEFAULT"
}

if (/^Cc:.*help@swcp.com/ )
{
to "$HELP"
}

if (/^From: My Enemy <anotheruser@swcp.com>/)
{
to "$SPAMCAN"
}

if (/^Subject: About your puppies/)
{
to "$DEFAULT"
}

=Filter Contents of the header, body, both, or case.=
You can match header, body, header & body, or case (upper or lower).

Header is always assumed, so you don't have to put :h after most matches
Be very careful to limit the size of your search if you use :b see below.

* :h = match in the header only
* :b = match in the body only
* :w = match in the header and the body
* :D = match case
* :p = match only the first 100 lines of the body (SWCP Specific)

==First Version==
This version matches the words opt-in, opt in, opt-out, opt out in the body with no reguard for the size of the message.

if (/(opt-in|opt in|opt-out|opt out) /:b )
{
to "$SPAMCAN"
}

==A Better Version==
This version matches the words opt-in, opt in, opt-out, opt out in the body but constrains the message size to less than 500 lines and less than 15 kilobytes.

if (($LINES < 500 && $SIZE < 15000) && /(opt-in|opt in|opt-out|opt out) /:b)
{
to "$SPAMCAN"
}

=Using Matching=
If you have multiple entries to match say from the Subject line, consider the following.

The special character '!' tells maildrop to stick everything it matches up to the end of line '$' into one of its special MATCH variables.

'''Note''': It should be noted that maildrop has (what I consider to be) a documented bug. Different types of matches cause different MATCH variables to be used. In particular if statements using this match syntax dump their variable contents into MATCH2, foreach matches dump their match contents into a variable called MATCH, see below.

if (/^Subject: *!.*$/)
{

if ($MATCH2 =~ /Updates from the hospital about (mom|dad|brother)/ )
{
to "$DEFAULT"
}

if ($MATCH2 =~ /Win / && $MATCH2 =~ /Opt/:D && /casino/:p)
{
to "$SPAMCAN"
}

}

=Looping with Foreach=
If you wish to match to & cc in the same statement you must use a foreach

foreach /^(To|Cc): *!.*$/
{
if ( $MATCH =~ /@netris.com/)
{
to "$DEFAULT"
}

if ($MATCH =~ /rob@nowhere.com / && /casino/:p )
{
to "$SPAMCAN"
}
}

=Dropping a message entirely=
If you want to send something to /dev/null, use the keyword 'exit'. It should send any matched email messages to /dev/null.

if ( /To: sampleuser@netris.com/)
{
exit
}

=Filter Then Forward=
If you want to filter then forward or cc a message, simply place a ! at the begining of your delivery line. This tells maildrop to forward all mail matching that criteria to someone@someotheraddress.com. If you want to forward all email simply put the 'cc' line outside the body of the regex.

if ( /To: sampleuser@netris.com/)
{
cc "!someone@someotheraddress.com"
}

=Testing your new filter rules=

Log into a a host that is running maildrop and run the following command*:

maildrop -V 4 -d logname < msg.txt

Where logname is your username and msg.txt is a file containing 1 email message saved from pine or mutt.

'''You'll probably want to log into a host other than your mailserver.''' If your system has a systemwide maildroprc you'll see all the debug from that too. That's probably not what you want :-)

==Shameless plug==

http://www.dillivision.com/felix - use my cat to help you manage your email.

=A real example=

MAILDIR="/users/$LOGNAME/mail"
DEFAULT="/var/mail/$LOGNAME"
SPAMCAN="/users/$LOGNAME/mail/SPAM"
logfile "/users/$LOGNAME/maildrop_log"
#
if(/^Subject: *!.*$/)
{
if($MATCH2 =~ /Dialup Session Report/)
{
log "Ptrn: Dialup Session Report"
to "$MAILDIR/portmasters"
}
if($MATCH2 =~ /OMS#.*Path Built/)
{
log "Ptrn: Path Built"
to "$MAILDIR/pathbuilt"
}
if($MATCH2 =~ /Domain request:/)
{
"Ptrn: Domain request"
to "$MAILDIR/domreg"
}
}
# end of Subject exceptions
#
# begin To/Cc exceptions
foreach /^(To|Cc): *!.*$/
{
if($MATCH =~ /ilikespam@/)
{
log "Ptrn: ilikespam spam"
to "$MAILDIR/throwaway"
}
if($MATCH =~ /abc@/)
{
log "Ptrn: abc spam"
to "$MAILDIR/throwaway"
}
if($MATCH =~ /puppyfriends@yahoogroups.com/)
{
log "Ptrn: Puppy email"
to "$MAILDIR/puppy"
}
}
# end of To and Cc exceptions
#
# beginning of From exceptions
if(/^From:*!.*$/)
{

if($MATCH2 =~ /joejoe@uswest.com/)
{
log "Ptrn: joejoe"
to "$MAILDIR/joe"
}
if($MATCH2 =~ /catchthisemail@swcp.com/)
{
log "Ptrn: catchthisemail spam"
to "$MAILDIR/junk"
}
if($MATCH2 =~ /((samplemom|sampledad|samplebrother|sistersample)@swcp.com)|marie@nm.net/)
{
log "Ptrn: family match"
to "$DEFAULT"
}
if($MATCH2 =~ /(majordomo@swcp.com|replies@opensrs.org)/)
{
log "Ptrn: majordomo-opensrs"
to "$DEFAULT"
}
}
# asdf end of From: exceptions
#
log "Ptrn: final match"
to "$SPAMCAN"

----

''The bulk of this document was written by [mailto:jamesh@swcp.com James Hamilton].