Basically the fix is this:

# nano /lists/admin/send_core.php

Find this

if (is_array($_POST["criteria_values"])) {
$values = join(“, “,$_POST["criteria_values"]);
} else {
$values = $_POST["criteria_values"];
}

and replace it with this

if (is_array($_POST["criteria_values"])) {
# The following code checks for null values in the criteria_attribute array and removes them
$values = $_POST["criteria_values"];
foreach ($values as $key=>$value) {
if (!$value) {
array_splice($values, $key, 1); // Remove null value from array
}
}
$values = join(“, “,$values);
# $values = join(“, “,$_POST["criteria_values"]);
} else {
$values = $_POST["criteria_values"];
}

Now everything should work, with no more mysql errors!

Apparently this howto:

http://www.newthink.net/2007/05/18/smarthost-authentication-with-sendmail/

Will get you going, but there is one critical change you must make as determined by the Hugo on the mailing list.

Don’t forget to use smtp-rog.mail.yahoo.com in authinf and not smtp.broadband.rogers.com!

Also, if you want to use an external authinfo file, add this to your sendmail.mc file.

FEATURE(`authinfo’, `hash -o /etc/mail/authinfo.db’)dnl

Again, I didn’t try this myself, but I know some of you use Rogers and this may come in handy.

Another Reference on SMTP and Rogers Smarthost with Sendmail is here.

We’re using Ubuntu Linux, and this tutorial assume you’ve already installed TRAC on a global basis to your development server.

So, lets get some themes installed on our Trac 10.x installation shall we?

First, install the pre-requisites if not already installed.

# apt-get install python2.5-setuptools

We had to change a couple permissions as well so Trac and everything can read/write where it needs to

# chown -R www-data:www-data /var/www

Now we had to install WebAdmin for Trac 10.x:

# svn export http://svn.edgewall.com/repos/trac/sandbox/webadmin/
# cd webadmin
# python setup.py bdist_egg
# easy_install -Z dist/*.egg

Note that WebAdmin is included with Trac 11.x if you’re bleeding edge, you probably don’t need this.

Now we had to install ThemeEnginePlugin for Trac 10.x:

# svn checkout http://trac-hacks.org/svn/themeengineplugin
# cd themeengineplugin
# cd 0.10
# python setup.py bdist_egg
# easy_install -Z dist/*.egg

Now, lets install some themes for Trac 10.x:

# svn checkout http://trac-hacks.org/svn/pydotorgtheme/
# cd pydotorgtheme/0.10/
# python setup.py bdist_egg
# easy_install -Z dist/*.egg
# cd ../../
# svn checkout http://trac-hacks.org/svn/gamedevtheme/
# cd gamedevtheme/0.10
# python setup.py bdist_egg
# easy_install -Z dist/*.egg
# cd ../../
# svn checkout http://trac-hacks.org/svn/consultanttheme/
# cd consultanttheme/0.10
# python setup.py bdist_egg
# easy_install -Z dist/*.egg
# cd ../../

Now we added the following to our Trac.ini within the project we want the themes to be used for:

# cd /var/local/trac/trac.yourdomain.com/conf/
# nano trac.ini

Add this to the components section of your configuration file

[components]
webadmin.* = enabled
themeengine.* = enabled

Then we restarted Apache and we were able to select themes to make available, and attach to our Trac Installation. Note that with each new theme added, you will have to restart Apache in our experience.

This should get you going with installing some themes for Trac on your Ubuntu Linux server. Have Fun!

We wanted to setup LigHTTPD, however it’s not nearly as easy because of no svn-dav module available, so we stuck with Apache 2 for now.

We found a howto on doing this, however there were a few vital steps and explanations missing so we’ve re-written it in hopes it will help others the trouble of searching to find this information.

So, lets move on to the tutorial shall we.

First install the required packages on your system. We started with a clean Ubuntu JEOS 8.0.4 Install on our server.

# sudo aptitude install enscript libapache2-mod-python python-docutils trac db4.3-util libapache2-svn subversion-tools

Now create a virtual host for your SVN container.

# mkdir -p /var/local/svn/svn.yourdomain.com

Now create a development group, and add the web user to it.

# addgroup svngroup; adduser www-data svngroup

Now Add a user to the system and add them to that group

# adduser username
# passwd username

Now add that user to the group required for SVN

# adduser username svngroup

Now setup the permissions for your SVN site.

# chmod 2770 /var/local/svn/svn.yourdomain.com

Now setup the repo as you normally would

# svnadmin create /var/local/svn/svn.yourdomain.com

Remove the current password file. We’re using HTTPS (or HTTP) instead of SVNSERVE so no need for it.

# rm /var/local/svn/svn.yourdomain.com/conf/passwd
# touch /var/local/svn/svn.yourdomain.com/conf/passwd

Allow your group to write to the repo

# chmod -R g+w www-data:svngroup /var/local/svn/svn.yourdomain.com

Now set the repo access permissions.

# nano /var/local/svn/svn.yourdomain.com/conf/authz

It should look something similar to the following. If in doubt, refer to the Path-Based Auth section of Subversion.

[groups]

svngroup = username1,username2,username2

[/]
@svngroup = rw

Now, create a log directory within apache for your development site.

# mkdir /var/log/apache2/svn.yourdomain.com

Now create your virtual host.

# nano /etc/apache2/sites-available/svn.yourdomain.com

Copy the following in, editing to suit your environment. Note we’re using a self signed certificate, you can change this to a properly signed one if you have it.

<VirtualHost [server's IP address]:443>
ServerName svn.yourdomain.com
<Location />
DAV svn
AuthType Basic
AuthName “svn.yourdomain.com”
AuthUserFile /var/local/svn/svn.yourdomain.com/conf/passwd
AuthzSVNAccessFile /var/local/svn/svn.yourdomain.com/conf/authz
SVNPath /var/local/svn/svn.yourdomain.com
Require valid-user
</Location>
CustomLog /var/log/apache2/svn.yourdomain.com/access.log combined
ErrorLog /var/log/apache2/svn.yourdomain.com/error.log
SSLEngine on
SSLCertificateFile /etc/ssl/certs/selfsigned.pem
# Add this once there is a real (non self-signed) certificate.
# SSLCertificateKeyFile /etc/apache2/ssl/server.key
</VirtualHost>
<VirtualHost [server's IP address]:80>
ServerName svn.yourdomain.com
Redirect / https://svn.yourdomain.com/
</VirtualHost>

Now, enable the site

# a2ensite svn.yourdomain.com

Now, create a username and password to access the svn site.

# htpasswd /var/local/svn/svn.yourdomain.com/conf/passwd username1

Now, create your SSL certificate. Details are here if you need them.

# sudo aptitude install ssl-cert

Now, we found out that the default Ubuntu SSL cert is only for 30 days, so, we changed this to be 365 a little more sane no? Thanks for the tip Devio.

# which make-ssl-cert
/usr/sbin/make-ssl-cert
# nano /usr/sbin/make-ssl-cert

Replace the line near the bottom that looks like this

openssl req -config $TMPFILE -new -x509 -nodes -out $output -keyout $output

With a line that looks like this instead

openssl req -config $TMPFILE -new -x509 -days 365 -nodes -out $output -keyout $output

Exit and save the file. Now we’re ready to generate our final self signed SSL certificate for Apache on Ubuntu. Like this;

# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/certs/selfsigned.pem

Make sure to set your “common name” to your server name – ie: svn.yourdomain.com

Now you can go ahead and restart Apache to verify your DAV enabled SVN site functions.

# /etc/init.d/apache2 restart

To verify, hit it’s url in a browser

https://svn.yourdomain.com/

If everthing was successful, you now have SVN setup, with WEB-Dav support in Apache2 on Ubuntu. Continue to setup Trac.

First we have to create the web directory for Trac.

# mkdir -p /var/local/trac/trac.yourdomain.com

Now we setup the permissions

# chmod 2770 /var/local/trac/trac.yourdomain.com

Create a Trac instance for your project

# trac-admin /var/local/trac/trac.yourdomain.com initenv

Setup the proper ownerships for the directory

# chown -R www-data:svngroup /var/local/trac/trac.yourdomain.com

Now make sure the group is added to the repo

# chmod -R g+w /var/local/trac/trac.yourdomain.com

Configure Trac where required

# nano /var/local/trac/trac.yourdomain.com/conf/trac.ini

Create a directory for log files

# mkdir /var/log/apache2/trac.yourdomain.com

Now create a virtual host for your trac instance

# nano /etc/apache2/sites-available/trac.yourdomain.com

Now, copy the following into the virtual host configuration, changing to suit your domain and configuration

# Trac Configuration
<VirtualHost [server's IP address]:80>
ServerName trac.yourdomain.com
Redirect / https://trac.yourdomain.com/
</VirtualHost>
<VirtualHost [server's IP address]:443>
ServerName trac.yourdomain.com
DocumentRoot /var/local/trac/trac.yourdomain.com/
Alias /trac/ /usr/share/trac/htdocs
<Directory “/usr/share/trac/htdocs/”>
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<Location />
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonInterpreter main_interpreter
PythonOption TracEnv /var/local/trac/trac.yourdomain.com/
PythonOption TracUriRoot /
AuthType Basic
AuthName “trac.yourdomain.com”
# Use the SVN password file.
AuthUserFile /var/local/svn/svn.yourdomain.com/conf/passwd
Require valid-user
</Location>
CustomLog /var/log/apache2/trac.yourdomain.com/access.log combined
ErrorLog /var/log/apache2/trac.yourdomain.com/error.log
SSLEngine on
SSLCertificateFile /etc/ssl/certs/selfsigned.pem
# Add this once there is a real (non self-signed) certificate.
# SSLCertificateKeyFile /etc/apache2/ssl/server.key
</VirtualHost>

Now, enable this virtual host as well

# a2ensite trac.yourdomain.com

Configure Trac Permissions for your Trac instance.

# trac-admin /var/local/trac/trac.yourdomain.com

Use the following commands to view permissions, and set permissions.

“help permission”

We set the following permissions to one of our users from the command line

# trac-admin /var/local/trac/trac.yourdomain.com permission add username1 TRAC_ADMIN

Now you’re ready to restart Apache with your new Trac VHOST.

# /etc/init.d/apache2 restart

Now you’re ready to restart Apache and visit your Trac installation

https://trac.yourdomain.com/

Login with your user (username1) and password you setup earlier.

We hope this tutorial helps others when trying to setup SVN and Trac on Ubuntu with Virtual Hosts. Let us know if you have any other handy tips!

He runs a support queue for his company. During the day he has a regular IVR with Call queues enabled to handle customer calls and direct them to the appropriate staff member to deal with customer inquiries etc. After hours the menu functions the same way, however there are less staff to answer the phones so mainly the emergency extension is the only one being monitored, for – well, emergencies!

Of course, the people monitoring for emergencies don’t want to get a call asking what the company address is at 4 o’clock in the morning. So our client wanted the ability to set his system up so all calls to the emergency queue would be directed out a specific channel on his DID with a specific CallerID.

This enables his staff to set their cell phones to “ignore all calls except for those from this number”. Of course they set “this number” to the one being used by the outbound PRI channel on the PBX.

Setup of is type of scenario is detailed below.

1. Login to your FreePBX Control Panel.

2. Go to the Trunks Menu and add a new ZAP trunk. Note this is different if you’re using SIP or IAX. Here, we’re using a T1 PRI.

3. When you create the new trunk, put in the following configuration variables.

Outbound Caller ID: “emer” <5555551212>
Never Override CallerID: <checked>
Maximum Channels: <set to max cellular phones used>
Disable Trunk: <unchecked>
Dial Rules: .
Outbound Dial Prefix: <blank>
Zap Identifier: g2

4. Your new trunk is now created in Asterisk.

5. Click on the Outbound Routes link item on the left of the FreePBX Control Panel.

6. Add a new Route and put in the following information:

Route Name: Emergency
Route Password: <blank>
PIN Set: None
Emergency Dialing: <unchecked>
Intra Company Route: <unchecked>
Music On Hold: Default
Dial Patters:

2133|NXXXXXX
2133|NXXXXXXXXX

Trunk Sequence: g2

Note the above and the “2133″ used. This number can be anything you want, we just chose something we knew wouldn’t be used in the next step of the configuration. This number will get stripped out before getting sent out the trunk so it’s really not a big deal what you pick here. Just use something that won’t be used anywhere.

7. Click on Submit changes in this menu to add your new route

8. Click on the Ring Groups Menu on the left side of FreePBX 2.5.1 Interface

9. Edit, or Create a new Ring Group for the Emergency Group and ensure that it has the following settings along with your own configuration customizations if you have made them (merge these in):

Ring Strategy: Ringall
Ring Time: 50 Seconds (Time appropriately for Cell Voicemail!)
Extension List:

21335555551212#
21335555551212#

Announcement: Change to your own if you want
Play MOH: Ring
CID Name Prefix: CompanyName
Confirm Calls: Checked
Remote Announce: Same as “Announcement”

Destination if no answer: Hangup (or whatever you need)

Note that the 2133 prefix’s the cellular phone example numbers above. If you changed that earlier make sure to change it here when you’re changing the mobile phone number.

10. Click on the submit button and you’re done adding your ring group to the configuration for this portion.

11. Click the “Queues” button on the left side of the FreePBX Management Interface and either modify or create a new queue for your Emergency staff.

12. When creating the new Queue use similar information to the following:

Queue Number: A extension for queue
CID Name: EMR-
Wait Time: No
Alert Info: Blank
Static Agents:

1234,0

Note that 1234 in this section is the number of your Ring Group used for the Emergency Dialing feature for Outbound calls.

Set your Agent Timeout to something respectible.

Agent Timeout: 40 seconds

Keep scrolling down the settings and set the “fail over destination” to your Emergency Queue (to itself).

13. Now you should ssh to the FreePBX server and create a change in the zaptel/dahdi configuration.

14. Edit the file like this

# nano /etc/asterisk/zapata.conf

15. Change it to something like this matching your system. We originally were using all 23 channels for the main line. Now we’ve separated it out into two groups (g1 and g2). G2 is the Trunk you setup earlier.

So, we started with:

group = 1
context=ext-did
switchtype=national
signalling=pri_cpe
stripmsd=1
channel=1-23

We ended with:

group = 1
context=ext-did
switchtype=national
signalling=pri_cpe
stripmsd=1
channel=1-22

group = 2
context=ext-did
switchtype=national
signalling=pri_cpe
stripmsd=0
channel=23

16. Exit and save the zapata.conf file.

17. Now you are ready to add this to your IVR menu and start testing.

18. Go back to FreePBX and go to the IVR menu option on the left of the Administration Panel. Find your IVR menu tree and add a new menu option to it that will dial your Emergency Queue.

19. You’re done. Give your menu a call, and hit the emergency queue!

If it doesn’t work, try the instructions again. If it still doesn’t work, leave us a comment and we’ll try to give you hand. Have you done something similar with FreePBX and Asterisk? Tell us about it below, we’d love to hear what other cool things people are doing.

We hope you enjoyed this howto!

I think this software could replace WordPress if done correctly, it will just take some time to get a little more robust, but the guts of it is definately there.

We recently installed Habari on one of our sites, and written this quick tutorial on how to get it going on your Ubuntu server using Apache.

We assume you’ve already got Mysql, PHP, SQLite and Apache installed on your server. If not, find some Howto’s on that because we’re not discussing it here.

So, first install some pre-requisite software:

# apt-get install libmysqlclient15-dev
# pecl install pdo pdo_mysql pdo_sqlite
# apt-get install sqlite3 libsqlite3-dev php5-sqlite3
# apt-get install php5-dev subversion

Now edit your php.ini

# nano /etc/php5/apache2/php.ini

add this to the bottom of the file:

extension=pdo.so
extension=pdo_sqlite.so

Now restart apache

# /etc/init.d/apache2 restart

Now create your Apache Virtual Host as per usual for your site.

Now enter your sites directory

# cd /home/username/public_html/sitename.com/htdocs/

Create the .htaccess file

# nano .htaccess

Enter something similar to the following for the contents of the htaccess file you just created.

### HABARI START
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteBase /
RewriteRule . index.php [PT]
### HABARI END

### HABARI SQLITE START
<Files “YOURSQLLITEDATABASENAME.db”>
Order deny,allow
deny from all
</Files>
### HABARI SQLITE END

Now download the Habari SVN

# svn checkout http://svn.habariproject.org/habari/trunk/htdocs .

We are using the MPM-ITK module with Apache. This means that all our sites are running per user, instead of as a global user. This is much more secure for multiple user or site environments. It’s very easy to get going in Ubuntu. Just do this.

# apt-get install apache2-mpm-itk

Then add this to whichever vhost you’re containing Habari

<IfModule mpm_itk_module>
AssignUserId username groupname
</IfModule>

This means we don’t have to setup crazy permissions for the Habari installer to function. If you don’t want to install MPM-ITK then you can simply follow the Habari Installation Instructions.

Now, to complete the install visit your site through

http://www.yourhabarisite.com/

The settings we used are the following:

Locale:
Set as “En-US”

Database Setup:
Database Type: sqlite
Data File: yourdomain.com.db
Table Prefix: habari__

Site Configuration:
Site Name: Site Name
Username: admin
Password: Your Password
Password: Your Password Repeated
Admin Email: contact@yourdomain.com

Plugins We left Enabled:
- Core Dash Modules
- Habari Media Silo
- Pingback
- Spam Checker
- Undelete

*NOTE*

We did have an error during installation when using SQLITE3. We had to modify the default Habari database schema to remove the “IF NOT EXIST” lines. Not sure why this was needed as apparently this support was added in Sqlite 3.3 and Ubuntu comes with 3.4 but whatever, very simple fix for the problem.

*NOTE*

Once this is done you should be complete the setup of Habari and can go ahead and install some Plugins or Themes.

We hope you enjoyed this tutorial, let us know if you have any other interesting Habari tips or tricks.

Basically the problem is:

Plesk runs apache as “www-data:www-data” while the users are “username:psacln”. So, uploading via sftp or ftp will work fine, but when you go to install something from the control panel in Joomla, it will be installed as www-data:www-data. Obviously, this is a problem since joomla won’t be able to run it properly.

So, our fix was this:

1. Install mod-itk

# apt-get install apache2-mpm-itk

2. Enter your VHOST directory

# cd /var/www/vhosts/[DOMAIN]/conf

3. Edit the vhosts file

# nano vhost.conf

4. Copy the following into the file, changing the user to your domain user.

<IfModule mpm_itk_module>
AssignUserId DOMAINUSER psacln
</IfModule>

5. Restart apache like this:

# /etc/init.d/apache2 restart

Now you should have apache back up, and each time it runs it will be running as your domain user, not www-data. Problem solved, without the use of php-cgi. Sweet!

first:

# sudo nano /etc/grub/menu.lst

look for

# defoptions= quiet splash

change it to – important leave the # in the line.

# defoptions=

now just run the grub updating tool and you’ll start up without the splash

# sudo update-grub

Easy eh?

1. SSH to server running nagios/nagiosadministrator

2. Go to your nagios administrator directory, ours is /var/www/nagiosadmin

3. Now, edit the menu file

# nano apps/backend/lib/topMenu.class.php

4. Now, change the first class topMenu from this

class topMenu
{
protected static $items = array(
‘contact’ => ‘Contacts’,
‘contactgroup’ => ‘Contact Groups’,
‘os’ => ‘Operating Systems’,
‘service’ => ‘Services’,
‘hostgroup’ => ‘Host Groups’,
‘host’ => ‘Hosts’,
‘command’ => ‘Commands’,
‘template’ => ‘Templates’,
‘generator’ => ‘Generator’
);

to this

class topMenu
{
protected static $items = array(
‘contact’ => ‘Contacts’,
‘contactgroup’ => ‘Contact Groups’,
‘os’ => ‘Operating Systems’,
‘service’ => ‘Services’,
‘hostgroup’ => ‘Host Groups’,
‘host’ => ‘Hosts’,
‘command’ => ‘Commands’,
‘template’ => ‘Templates’,
‘generator’ => ‘Generator’,
‘nagios’ => ‘Go To Nagios’
);

5. Refresh the Nagios Administrator web interface, and you’ll see a fancy new button you can click on to take you right to nagios.

Enjoy!

“VCommand error: This product has expired.”

This box holds some Asterisk Development stuff and some other Dev systems that we couldn’t really have go down on us. So, we downgraded our VMWare 2.x Server to the latest 1.x branch of VMWare. Then on we went to importing Virtual Machines from Server 2.0 and Workstation 6. As soon as we started to power them on, the fun started. Of course! The VM’s weren’t compatible anymore and gave us a couple errors. Here’s how we fixed it.

The first error we received was:

“A General System Error Occurred: Unknown Error”

This happened as soon as we tried to power on the VM. This was easily fixed. We entered the Virtual Machine’s directory, and edited the .vmx file for the virtual machine, this is just plain text. Replacing the next few lines fixed it right up for us.

config.version = “8″
virtualHW.version = “6″

became

config.version = “4″
virtualHW.version = “4″

Now we could power them up. However, we now encountered another error that we couldn’t open the virtual disk we had created. The error was something about how the Virtual Disks were created in a later version of vmware, and couldn’t be mounted. We’d have to re-create them. Obviously this wasn’t an option.

In some of the Virtual Machine directories, we had a file to edit with a text editor, this was simple enough.

# nano virtualdiskname.vmxf

Then change this:

ddb.virtualHWVersion = “6″

became

ddb.virtualHWVersion = “4″

However, some of the other directories (mainly the ones created with VmWare Workstation 6) did not have a simple text file to edit, instead we had to edit the actual virtual disk using a hex editor. We chose the wonderful heme editor. Usage Instructions for Heme are here.

Basically put, do this:

# heme virtualdisk.vmdk

Now press “w” on your keyboard to search for “virtualHWVersion“. You will find it in the ascii column eventually. Hit “TAB” to enter Ascii mode, move your cursor with the arrow keys to where you need to replace the number. Replace the “8” or the “6” with a “4” and then press “s” to save the file. Answer yes to saving and then wait for it to save. Now exit the program by pressing “q“. You’ll notice it created a backup file with the “~” extension on it incase you messed up the hex editing. Leave this backup file here for now. Continue on, nothing to see here.

Now on the VMWare server, make sure that all the files in the virtual machine directory are chmodd’d properly.

# cd /virtual machine/directory/

# chown user:group *
# chmod og=rwx *

Now you should be able to start your vm without any issues.

If it all works, feel free to delete the backup .vmdk~ that heme created for you.

Good luck!