There must be something useful here…

I used to have a Wiki that I would keep track of all of the “Cool Commands” that I found or created.  But now that Wiki is down and I haven’t had the time to put it back up.  So, I need to keep track of commands so I don’t forget them.   Alright, starting off, have you ever wanted to change a few lines of text in a bunch of files?  I have.  I found a one line Perl script that will take care of it for you, and leave you a backup file for your trouble.

• perl -pi -i.bak -e ’s/searchval/replaceval/’ *.html

This command can use regular expressions for the search value and the replace value.

This next command will sync your information and can be used to only keep updated copies of files.   There are lots of options too, this only scratches the surface.

• rsync -uav --progress /srcdir/ /dstdir/

This command will will look at the srcdir and then determine if the dstdir file is newer, if it is, it won’t copy.  Very useful if you need to merge multiple copies of files, but don’t want duplicates.

This next command will find files for you based on all sorts of criteria:

• find . -mtime -10

This command will look for files that are -10 days old.

You can combine rsync and find to search for files and then sync those files.

• find . -mtime -10 -print0 | rsync -av --progress --files-from=- -from0

This command will first compile a list of files that meet the find criteria and then will port them to rsync.  Very helpful.

Ok, that is all the cool commands for today, I will probably find some more tomorrow.

Found more… This command will make a file of any size for you:

• dd if=/dev/zero of=file.out bs=1MB count=100

This command will create a 100 meg dummy file. Works great.

Mike

For the issues I have been having with the above formula, I decided to write up my experience in hopes that I can either help someone or at least provide a few little details to make some sense of things.

First off, I just want to say, that if you, as a programmer, choose to use Perl, and then further choose to design a full web application with Perl, PLEASE, PLEASE use the CGI-BIN file so that for future programmers on your project may be able to move your project without an act of congress.  KEEP THINGS SIMPLE!!!

Ok, here is the preface of the situation, A company I have been working with for a few months has a large number of antiquated servers.  They purchased some new ones and then wanted to move everything to the new servers.  This seems like a not too difficult task, the source machines are Fedora.  I opted for the newest release of Ubuntu because of the many new features like integrated cloud control and the fact that it is built on Debian.  Don’t boo me since I am taking the easy road, there is a Sonic wall that will do the filtering and provide a very high level of security and IDS.  Since this is not a post on security I won’t get into the details of my security plan.

Once LAMP and IspCP was all setup, it was time for the copy.  After I had a complete copy of all the files, I began filling out the holes of the new, empty webserver.  For anyone who has messed with IspCP, you will know that it uses /var/www/virtual/[domain name]/htdocs to store the web accessible files.  The cgi-bin folder is stored at the same level as htdocs.

I began populating htdocs with the info from the previous server and everything starting going fine.  Even all of the PHP files worked and executed properly thanks to settings in IspCP.  The issue, Perl was sprinkled throughout much of the web applications.  Many database calls and functions were all written in Perl.  One would think that this isn’t a big deal and that with a few apt-get calls, everything would work out.

The major issue is that it was the intention of the “Elders of The Internet” to store executable files in the cgi-bin.  And from my research (which is many hours at this point), it seems Apache2 with Virtual Hosts is dedicated to following these directives.  After hours of messing with the apache2.conf, ispcp.con, and other config files, I finally have found a work around that is not convenient, but workable.

Inside the virtual host file ispcp.conf (in /etc/apache2/site-enabled/ispcp.conf) under the <VirtualHost> directive, you can place:

AddHandler cgi-script .pl .html
Options +ExecCGI

Inside the same file, inside the <Directory *> directive you can place the same information as above to have it apply only to the specific directory.  However, this only works with directories at the same level or deeper in the tree. (Eg. /here or /here/nowhere).  When I would try to use a directory outside the VirtualHost document root, I would get an Internal Error 500 with the suexec.log file saying that the directory had other write permissions enabled…. Very strange.

The things that don’t work, and guarantee Internal Error 500 are adding the <file ~ .pl> with the file handlers for perl scripts to apache2.conf.  If you try to add an ‘*’ to the directory in the above example, it causes a 500 error.

Finally, I found out the hard way that make changes to the ispcp.conf file don’t stay if someone adds a new website or addon.  Instead you must modify the following file to make it persistent.  /etc/ispcp/apache/working/ispcp.conf

Now back to adding the top directive to the subdirectories.

***UPDATE:  It seems that the previous practice I prescribed earlier has failed.  When I added all of the info to the ispcp.conf, it gave me another Internal Error 500.  This time it was saying a file was writeable by others.  To compound the issue, it looks like Firefox and IE were both reporting Cached pages.  I found a setting in IE to only pull fresh, new copies everytime.  I figured a CTRL+F5 would give me a fresh copy.  It looks like the solution was to add AddHandler cgi-script .pl .html Options +ExecCGI to the .htaccess file.  But now when I add it to a subdomain I am back to the stupid issue with the internal error 500.  I am going to bed.

Good Luck,

Mike