Browsing articles tagged with " php"

External notification script patch for Observium

I’ve written a patch for Observium¬†0.12.9.3385 that defines a couple of additional configuration options. When set, these allow Observium to call an additional external script for notifications in addition to the default mail notification method. This is useful for SMS notifications, although it could be used for any notification via a script or command. It expects the script to accept the notification text from STDIN, and respects the per-device notifications-disabled setting on the device configuration tab.

 

The following configuration options are defined:

$config['alerts']['script']['enable'] = TRUE|FALSE;
$config['alerts']['script']['file'] = "/path/to/script-file";

 

external_notifications.patch

*** includes/functions.php.dist 2012-11-23 05:52:27.769189651 +0000
--- includes/functions.php      2012-11-25 10:19:48.309370976 +0000
***************
*** 707,712 ****
--- 707,726 ----
        }
      }
    }
+
+   if ($config['alerts']['script']['enable'] && $config['alerts']['script']['file'] && !get_dev_attrib($device,'disable_notify'))
+   {
+     if (!get_dev_attrib($device,'disable_notify'))
+     {
+       $script = popen($config['alerts']['script']['file'], "w");
+       if($script){
+         fwrite($script, $message."\r\n");
+       }else{
+         echo "Notification Script Error!\n";
+       }
+       pclose($script);
+     }
+   }
  }

  function formatCiscoHardware(&$device, $short = false)

WebDAV revisited

In my previous endeavour with WebDAV, I ended up using a complicated lighttpd/apache proxy system to get the permissions right. This did work well enough, but it had a few limitations. In involved modifying the registry on the client systems and it required a new lighty instance running for each share with different permissions to the last (which wasn’t terribly efficient). Additionally, lighty’s mod_webdav lacked support for a few vital operations which made working with the shares a bit difficult, not to mention there were some MIME-type conflicts between lighty/apache/the webDAV client that made working with certain types of files near impossible.

I have since revised some of the methods I’ve used to implement the WebDAV server. For a start, I managed to resolve the XP SP2/Vista/7 basic vs DIGEST authentication method hacks to not need registry editing – it turns out, by default, if the share is SSL encrypted, basic authentication should be fine. I also decided on a new approach. Using Apache, PHP5, suPHP and eZ Component’s WebDAV module, I was able to implement a sturdier WebDAV solutions that still solved the problems.

First things first, Apache, PHP5, mod_php, mod_suphp all needed to be installed and configured. Once that was done, ez Component’s WebDAV module needed to be installed – on Fedora, this is php-ezc-Webdav in the Yum repositories. Then I needed to make a couple of scripts to handle authentication and module loading. These are modified right from the ezc-Webdav documentation. These scripts need to go in Apache’s DocumentRoot.

autoload.php

<?php
require_once "/usr/share/pear/ezc/Base/base.php";

/**
 * Autoload ezc classes
 *
 * @param string $className
 */
function __autoload( $className )
{
    ezcBase::autoload( $className );
}
?>

You may need to alter the path to base.php above.

authenticator.php

<?php
class ldapAuthenticator extends ezcWebdavDigestAuthenticatorBase
                   implements ezcWebdavAuthorizer
{

    public function authenticateAnonymous( ezcWebdavAnonymousAuth $data )
    {
        return false;
    }

    public function authenticateBasic( ezcWebdavBasicAuth $data )
    {
        $username = $data->username;
        $password = $data->password;

	if(strstr($username, '\\')){
		$username = strstr($username, '\\');
		$username = preg_replace("^.", '', $username);
	}

	$ldap = ldap_connect("ldap.company.tld", 389);
	$bind = @ldap_bind($ldap);
	$search = ldap_search($ldap, "dc=company,dc=tld", "(&(objectClass=shadowAccount)(uid=".$username."))", array("dn"));
	$data = ldap_get_entries($ldap, $search);
	$dn = $data[0]['dn'];

	if(!$dn){ return false; }

	$bind = @ldap_bind($ldap, $dn, $password);
	$search = ldap_search($ldap, "dc=company,dc=tld", "(&(objectClass=shadowAccount)(uid=".$username."))", array("dn"));
	$data = ldap_get_entries($ldap, $search);

	if(!$bind){ return false; }

	return true;
    }

    public function authenticateDigest( ezcWebdavDigestAuth $data )
    {
        $username = $data->username;

	error_log("User attempted unsupported DIGEST authentication: ".$username);

	return false;
   } 

    public function authorize( $user, $path, $access = ezcWebdavAuthorizer::ACCESS_READ )
    {
        return true;
    }
}
?>

You will need to modify the authenticateBasic function. The one above is to authenticate with an LDAP backend.

sharename.php

<?php
require_once 'autoload.php';
require_once 'authenticator.php';

$server = ezcWebdavServer::getInstance();

$server->options->realm = "CCPG Solutions Ltd WebDAV";

$server->auth = new ldapAuthenticator();

$backend = new ezcWebdavFileBackend(
   '/path/to/share'
);

$server->handle( $backend );
?>

In this one, you will need to modify the share path (in $backend) and the realm.

Then you need to change the owning uid/gid (chown user:group sharename.php) of the sharename.php file to the user/group you want to use for read/write permissions of the files. You can make as many sharename.php files for each share (or combination of share/permissions) you need.

With all that done, you should be able to go ahead and map the share using the URL https://dav.company.tld/sharename.php

The eZ Component’s WebDAV module seems pretty in-depth – the above is really just a very basic usage of it’s capabilities, but it does work pretty well. The only other thing you may have to do, depending how pedantic your Windows boxes are going to be, is disable the DIGEST authentication headers altogether. To do this, edit /usr/share/pear/ezc/Webdav/servers.php (or wherever your Webdav/server.php is located) and comment the following lines in the createUnauthenticatedResponse function:

$wwwAuthHeader['digest'] = 'Digest realm="' .$this->options->realm . '"'
 . ', nonce="' . $this->getNonce() . '"'
 . ', algorithm="MD5"';

Save the file and exit. That’s all it takes. With all that done, your users should be able to map the share in Windows, authenticate via LDAP and read/write files with the permissions of the PHP script owner.

uop2cal: Subscribe to your @PortsmouthUni timetable as an iCal feed (UPyoursUPlink?)

Anyone who goes to the University of Portsmouth will be familiar with UPlink, the University’s portal system, and with the timetable it contains. Most people (especially anyone under what used to be ECE) will be familiar with the frustration of lectures changing times/dates/moving room/no longer existing despite being marked as “confirmed”, and the univeristy-standard oh-so-helpful response of “You should be checking it everyday”, along with the other dozen-or-so university sites we’re supposed to be checking every day. (Can you notice my frustration yet? I was originally planning to call this UPyoursUPlink but have since decided on the less-offensive but less-descriptive uop2cal)

This script is a pretty simple one, it uses cURL to screen-scrape the portal and retrieve your timetable, an obnoxious set of regexes (<3) to parse the data into an array, and then the iCalcreator class to generate an ICS file of your timetable, complete with the details (name, lecturer, room, confirmed/unconfirmed (not that I can find a difference, mind), group, etc).

Update: Previously, I was supplying a hosted copy for anyone to use, but I have been advised by the University that you willingly giving me your username and password somehow contravenes the Computer Misuse Act 1990. Whether or not this is the case is irrelevant, as they have asked I stopped doing this. In any case, the source code is still available below (unless they later tell me that’s a problem somehow, too), so you can run your own copy.

Update update: Apparently the University still weren’t too happy with the provisions I had made the last time they contacted me, and have once again requested I remove this. As such, this source is no longer publicly available. Queries about why can be directed towards the University itself, queries about the source are welcome to me.

PHPhruitwall

Script Information

PHPhruitWall is the PHP rendition of a Perl script (“fruitwall”) from the PhoneLosers of America that acts as a tagboard of sorts. The fruitwall is included into a page, and shows a short message. Anybody can click on that message, and change it, to read a new message. The messages and IP addresses are archived, so that by clicking the ‘archive’ link, you are able to see all of the messages in the fruitwall’s archive. This script is considered obsolete — I’m unsure at this time if it will work with current versions of PHP whilst unmodified, I can’t even remember what the REGISTER_GLOBALS method used on it was. This was written quite some time ago. It is available for download here, although I’m starting to toy with the idea of a new ajax-y version of the script. Maybe. Keep your eye out.