Normally installing a network capable printer is a routine task. Install the drivers, select the port you want to use (tcp/ip), and for the most part go. Yes I’m over simplifying the process, but not by much.  Installing the x9350 though wasn’t even close to this procedure.  First of all I could not simply add the printer through add printers, even as the administrator. I was forced to use the Lexmark installer, which is a bit odd, but not immediately problematic.  However the installer would not see the printer on the network. I could install it just fine with the usb cable, but that defeats the purpose of having it as a network printer, unless I want to chain it to another print server of some form.

So I called Lexmark tech support, and yes, the techs are in India.  And while I have no doubt our Indian IT counterparts are more then qualified to handle support calls, it doesn’t make their accents any easier to understand. Nothing personal, and I don’t mean to knock their abilities, but when I’m already frustrated by an unusual and needlessly difficult printer install, it would certainly make things a bit easier if I could readily understand the person trying to help (Are you listening Lexmark????).  With that said, they were obviously having a hard time understanding me as well, because even after repeating it a number of times and to a number of tech’s, they kept insisting that I was trying to set this up as a wireless printer. I even asked them to remove any instances of wireless anything from my support ticket, though that proved to be about as futile as this printers ability to connect across the WAN.  Finally after stumping a couple of techs I was transferred to network support and got a tech who seemed to speak English as a first language.  She again guided me through the install from start to end, only to achieve the same results I did, no x9350 printer in windows printers.  She put me on hold to consult another IT staffer, who then told her that all network ink jet printers use MAC address as opposed to TCP\IP to simplify the installation and make it easier for the installer to find. MAC addresses are not however route capable and thus I will not be able to use this network printer on our network. Which leaves me at the point I stated at the beginning of this blog post, as I am currently waiting for my RMA to send this printer back to our supplier.

To sum things up, I never was able to use this printer because Lexmark decided to create a port / protocol that is incompatible with the standard tcp/ip port already present in EVERY Operating System. And Lexmark has needlessly hurt their own product by trying to simplify an already easy operation. And for the people who would have difficulties setting up a network printer, those people would have to call tech support anyway, which just makes their attempt at simplifying this process a completely mute point.  I will certainly think twice before purchasing a Lexmark printer in the future, and well given the same amount of time to read reviews etc prior to buying a new printer, I’ll just assume Lexmark does not make a product that will fit our business needs and start my search with their competitors. If I were to give them a score between 1 – 10, Lexmark would have to provide me the points to achieve a positive integer.

If you look through the package, you will see that it already has quite a bit of functionality built in. In fact, it really has most everything you would need to automate the web hosting process. However that’s not enough for us, we want more!

The first thing we are going to want to edit is the new subroutine in the Accounting package. You can see it is stubbed out already:

sub new {
    my ($host);
    my ($user);
    my ($accesshash);
    my ($error);
    my ($usessl);
    my ($timeout) = 300;
    my $self = {};

    bless($self);

    return ($self);
}

This function is going to need to establish 4 things that we will use for the API calls. First, a host name. Simple enough. Second, a user. Generally, this is root, though it can be just about anyone with WHM access. Third, an accesshash. This can be found in the user we specified’s home directory in a text file called .accesshash. If one doesn’t exist, login to WHM through the web interface (https://yoursever:2087/ and goto the remote access hash link and it will generate and create said text document. Finally, we need to know whether or not to use SSL to communicate. There are very few times when you want that to be no.

My changed new subroutine looks something like this:

sub new {
    my $class = shift;
    my $name = shift;
    my $user = shift;
    my $accesshash = shift;
    my $usessl = shift;
    my $self = {
       host => $name,
       user => $user,
       accesshash => $accesshash,
       error => "",
       usessl => $usessl,
       timeout => 300
    };
    bless($self, $class);
    return ($self);
}

This is an overly simplified example of a possible solution. In my production code, I use a Class::DBI based class to pull the info I need from a database and pass it into here where this subroutine extracts the information it needs. Pretty easy, isn’t it?

Next we create a stub program to use the package we just edited.

#! /usr/bin/perl -w

use lib "/usr/local/hsw/libs/";
use C::Accounting;
use Data::Dump;

my $name = shift @ARGV || "server1";
my $func = shift @ARGV || "listxmlapps";

open(AHASH, "/root/.accesshash");
my @access = ;
close AHASH;
my $accesshash = join("\n", @access);

my $whm = C::Accounting($name.".mydomain.com", "root", $accesshash, 1);
print "Running ".$func." on ".$name." with ".join(" ", @ARGV)."\n";
my $t;
eval '$t = $whm->'.$func.'(@ARGV)'; # If you have a better way of doing
                                    # this, please let me know!
if($@) { print "ERROR : ".$@."\n"; }
if($s->{error} ne "") { print "ERROR : ".$s->{error}."\n"; }
Data::Dump->dump([[$t]]);

So here we take the first two arguments passed in on ARGV, and assign them to the host and a function for us to run on it. We get the access hash from root’s home directory then we create an Accounting object. I use eval to run the function that was passed in on Accounting object and pass it in what is left in ARGV, if anything. We do some error checking and display them if they exist, then I used Data::Dump to result to the screen. Simple, but it gives us what we need to see the API at work.

If we run this from the commandline, we get something like this:

-bash-3.2# ./testnsclient
Running listxmlapps on server1 with
(
  "C::Dump",
  [
    [
      {
        app => [
                 "adddns",
                 "addip",
                 "applist",
                 "delip",
                 "dumpzone",
                 "fetchsslinfo",
                 "gethostname",
                 "getlanglist",
                 "killdns",
                 "listacls",
                 "listcrts",
                 "listips",
                 "listzones",
                 "loadavg",
                 "lookupnsip",
                 "myprivs",
                 "nvget",
                 "nvset",
                 "passwd",
                 "reboot",
                 "restartservice",
                 "sethostname",
                 "setresolvers",
                 "version",
               ],
      },
    ],
  ],
)

By throwing in a few arguments, we run a different function:

-bash-3.2# ./testnsclient server1 loadavg
Running loadavg on server1 with
(
  "C::Dump",
  [[{ fifteen => "0.14", five => "0.18", one => "0.17" }]],
)

So awesome! Now what if we want to expand on this to do something cPanel doesn’t natively do? Suppose we wanted more information than what the loadavg command just gave us? Well, we need to goto the cPanel server itself. We navigate to /usr/local/cpanel/whostmgr/docroot and create a directory in there for our functions. We could create files directly in the docroot, but we don’t want our stuff interfering with cPanel’s, nor vice versa. I called mine hsw. In there, let’s create a file called load.cgi and put this inside:

#! /usr/bin/perl -w

use strict;
use CGI;

my $q = new CGI;
print $q->header();
open(ME, "|-", "cat /proc/loadavg");
while()
{
  print $_;
}

Chmod the file to be 755 and run it, it gives this:

-bash-3.2# ./load.cgi
Content-Type: text/html; charset=ISO-8859-1

0.28 0.18 0.15 2/96 12631

Great! So that works. Now we head back to our C::Accounting package and we add a function to handle this new functionality.

sub load
{
    my ($self) = @_;
    my (%PKGS);

    my (@PAGE) = $self->whmreq("/hsw/load.cgi");

    if ( $self->{error} ne "" ) { return (); }

    foreach $_ (@PAGE) {
        s/\n//g;
        my @contents = split(/\s/, $_);
        $PKGS{"1min"}    = $contents[0];
        $PKGS{"5min"}    = $contents[1];
        $PKGS{"15min"}   = $contents[2];
        my @procs = split(/\//, $contents[3]);
        $PKGS{"running"} = $procs[0];
        $PKGS{"total"}   = $procs[1];
        $PKGS{"lastPID"} = $contents[4];
    }
    return \%PKGS;
}

So we run the subroutine whmreq with the path to our script as an argument. We are given back an array of lines that were returned. We simply parse that out and assign the information to appropriate indexes in a hash table. We then pass the reference of the hash back. By running our stub-app, we get the following:

-bash-3.2# ./testnsclient server1 load
Running load on server1 with
(
  "C::Dump",
  [
    [
      {
        "15min" => "0.10",
        "1min"  => "0.07",
        "5min"  => "0.13",
        lastPID => 21897,
        running => 1,
        total   => 89,
      },
    ],
  ],
)

Well, that gives you the basics you need to expand the capability of cPanel/WHM’s API to include your own functionality and subroutines. Now you can get your cpanel/WHM boxes, even the DNS Only versions, to do anything that perl can do… remotely and programmatically.

This is a very powerful tool, use it wisely.

#! /usr/bin/perl
use strict;
use IO::Socket;
my $server = IO::Socket::INET->new
                          (
                            LocalPort => 9876,
                            Type => SOCK_STREAM,
                            Reuse => 1,
                            Listen => 10
                          )
                          or die "Unable to create socket.\n";

So first we create the socket with port 9876, make it a socket stream, set it to be reusable, and give it a queue listening size. If we are unable to create the stream, there isn’t much point of continuing (at least in this example) so we die.

my $connect = 0;
print "Waiting for a connection...\n";
while (my $cli = $server->accept())
{

We initialize a variable to keep track of how many connections we have going and then start the while loop that operates as long as we are able to accept a connection.

  if(fork() == 0))
  {

Once we get a connection, we fork, and if fork == 0 then we know we’re the child process and therefore we will handle the request!

    print "Connection received (#$connect)\n";
    while(<$cli>)
    {
      $connect++;

So now we loop through and read the input from the socket

      print "recieved $_";
      $result = eval ($_);
      print "result is $result\n";
      print $cli "$result\n";

So we read in the data, eval it, and return the result to the client … wouldn’t ever want to do this for real, but it makes a good example!

    }
    print "Terminating connection #$connect\n";
    exit 0;

We exit now (being the child process).

  }
  print "Waiting for connection #$connect\n";
}

And that’s it! Give it a shot, play around with it. This also works really well with the Daemon Making Tutorial to make a server daemon. Enjoy!

Also, don’t forget to grab your copy of Firefox 3 today!