2011 September | shallop.com

Web Services with PHP & nuSoap – Part 1.1

Posted by : Micheal Shallop Posted on : 26-09-2011

(1 votes, average: 5.00 out of 5)

Loading ...

Category : Technical

Tags: apache, client, code, curl, http, LAMP, newsoap, nusoap, PHP, programming, rpc, server, services, soap, source, technical, tns, tutorial, web, webservices, wsdl, XML, xsd

Introduction

[EDIT] – This is a re-hash of a document I wrote a couple years ago. There’s been changes to the nuSOAP library and I wanted to document the updates relative to the tutorial series. Also, I need to fix a lot of the broken-links and code listings since I’ve changes hosting providers since this article was first written.

This article is specific to nuSOAP release 0.9.5 on 2011-01-13. This tutorial was updated on September 22, 2011.

Once upon a time, I was tasked with developing a web-services by my boss as the integration point between our production application and Sales Force. At this point, although I’d heard of web services … kind of … didn’t Amazon use web services for something? Still, I’d never coded a web-services based application before.

At this point, I have to assume you are unfamiliar with the concept of web services and why you may have to create and provide a web-services offering to your client base. Web services allow a remote client to access functionality (as defined by you, the programmer) via the standard HTTP interface (normally, port:80) to your application and database services.

Back in the day, networking services (semaphores, pipes, streams, message queues, and other forms of IPC) were custom-written and assigned/slaved to unique networking ports for accessing specific service daemons. Of course, the internet was a kinder, gentler place back then… and a given server may have had dozens, or even hundreds, of non-standard ports open, listening, waiting, for networking service requests. Or hacking attempts.

Today, web-services is a replacement to dedicated networking apps – all handled by your web server, and all serviced over the same network port: port 80. Since port 80 is a standard port and, usually, already open on a web-server, additional security risks by opening new non-standard ports for networking services are averted. Your web-server, such as Apache, now has the responsibility of processing the request and delivering the results to the client.

The web-services component piece is a collection of functions that you’ve written that provide remote clients access to your system. These functions are accessible only via the web services framework and while they may be duplicated from a dedicated and traditional web-based application, the web-services framework is designed as a stand-alone piece of software. Think of the web-services piece as your application’s data-processing layer minus the presentation layer. The “M” and “C” of the “MVC” model.

Initially, when I was tasked with a similar set of objectives, I initially tried xml-rpc. This led me down a rabbit-hole that spanned nearly a week of my time with the end-result being abandonment. I hit road-blocks with xml-rpc over server authentication and passing complex objects. Exacerbating the issue overall is that xml-rpc seems to be dated technology – I had a hard time locating resources that were recent.

Then I stumbled across nuSOAP – it’s free via sourceForge, stable and, using a quote from sourceForge:

“NuSOAP is a rewrite of SOAPx4, provided by NuSphere and Dietrich Ayala. It is a set of PHP classes – no PHP extensions required – that allow developers to create and consume web services based on SOAP 1.1, WSDL 1.1 and HTTP 1.0/1.1.”

nuSOAP seemed to have more of everything available: tutorials, examples, articles, blog posts. When I started my implementation with nuSOAP, the first thing I received help with was server-level authentication. I was able to immediately get my remote requests validated by the web-server and handed off to the web-services module!

The major selling point, for me, on nuSOAP is that nuSOAP is self-documenting. As part of the API functionality, nuSOAP generates HTML pages that documents the exposed services via the WSDL and also provides you with a complete XSLT definition file!

First off, download and install the nuSOAP libraries – I provided a link to the sourceForge site a couple paragraphs ago – and unpack the tarball. You’ll end-up with a directory (mine is called: ./nuSOAP) and, within that directory, is the one file you include: nusoap.php.

There are two pieces to this tutorial — a server side piece and a client-side piece. While you can execute both pieces off the same environment (machine), normally you’d use the client remotely to access the API server-side code.

What’s Not Covered:

Apache. Apache configuration for your vhost. Apache .htaccess. This article assumes that you’ve a working server and that you’re able to install and access the server files via Apache. Even if your Apache server is a localhost configuration, access the server-side files via localhost client, traversing the TCP stack locally, is still a valid method for testing your web-services server application.

Time to push up our sleeves and start working on the server code…

The Web-Services Server

Today, we’re going to write a ping server — where the server has an exposed service (method) named “ping” which takes a single argument (a string) and returns an array back to the calling client. The return array contains two associative members: a boolean (which should always be true – otherwise there are other issues…) and a string which is the modification of the original string in order to prove that, yes, we went there and we came back.

Because my project, and I’m doing this project for my new company, is going to represent significant effort, size and complexity, I’ve broken out the components of nuSOAP request into exterior files because, later, these will become control file which will, in turn, load files that have been organized into a hierarchy friendly to the application’s data model.

So, if this file, which I’ve named index.php, seems small, remember that you’re not viewing the dependent files (yet).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<pre><?php
/**
*
*/

// setup...
require('./nuSOAP/nusoap.php');
// set namespace and initiate soap_server instance
$namespace = "http://myapi/index.php";
$server = new soap_server('');
// name the api
$server->configureWSDL("myapi");
// assign namespace
$server->wsdl->schemaTargetNamespace = $namespace;
// register services
require('myServiceRegistrations.php');
// load WSDL...
include('mywsdl.php');
// load services code modules...
require('myServicesModules.php');
// create HHTP listener:
$request = isset($HTTP_RAW_POST_DATA) ? $HTTP_RAW_POST_DATA : '';
$server->service($request);
exit();
?></pre>

So far, so good – let’s take a look at what we’ve just done:

we’ve included the nu_soap library…
declared our namespace (which is the URL of the api server)
instantiated a new soap_server instance and assigned it to the variable $server
initialized the WSDL
assigned the namespace variable to the WSDL
load and register our exposed services
load the WSDL
load the service code
create the HTTP listener
invoke the requested service
exit

This (index.php) file is the server-side file that will be invoked for ALL future API calls to the service. It invokes three control files which, in turn loads the services (WSDL definitions), the WSDL variable definitions (think of these as inputs and outputs to your exposed services), and the actual code for all of the services, and their supporting functions, that you’re going to expose via your API.

Side Note: This is the file you’ll reference in Apache when you’re (preferably) creating a new Virtual Host for the API. HTTP requests that resolve to your server will be serviced by Apache which will, in turn, serve the results of this program back to the client.

Next, we’re going to define the myServiceRegistrations.php file that is required by index.php. This file contains the WSDL for each and every exposed service that the API serves.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<pre><?php
/**
*
*
*/

$server->register('ping', array('testString' => 'xsd:string'),
array('return' => 'tns:aryReturn'),
$namespace, false, 'rpc', 'encoded',
'Summary: returns response to a ping request from the client. Response
includes testString submitted. Used to test Server response/connectivity.


Input: $testString (type: string) and random collection suffices.


Response: Service returns an array named $aryReturn with two associative
members: "status" and "data". $aryReturn["status"] should
always return true. (A time-out is an implicit false.) If no value was passed
to the service via $testString, then the value of $aryReturn["data"] will be
empty. Otherwise it will contain the string: "Rcvd: {yourString} (count)" to
show that the message was received and returned. (count) is a character count of the
passed string, also validating that the passed data was received and processed.

');</pre>

This PHP code registers a function called “ping” with the nuSOAP $server instance. The second parameter is the input to function. Note that all input (and output) parameters have to be declared as an array even if there’s only a single value being passed. Also notice that you have to type-cast the variable being passed using XML datatypes. For your data definitions, you use one of the 44 built-in datatypes defined in this document: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.

(For more information on XSD object and XML schema, please visit: http://ws.apache.org/axis/cpp/arch/XSD_Objects.html.)

The third argument to the method “register” is the data type returned. This is a complex variable called “aryReturn” — don’t worry about right now, we’re going to define this complex-type variable in another configuration file.

The next four arguments are:

our $namespace variable we set in index.php
boolean false
‘rpc’ for the call type
‘encoded’

Use these values literally.

The last variable is a huge block of HTML. This block of HTML can be as large, or as small, as you need it to be. It’s the basis for the WSDL documentation that nuSOAP generates for your client-side developers.

When developers hit the server URL, they’ll be presented with your API documentation that nuSOAP generates from the WSDL file(s). As your API grows, exposed methods will be listed in the blue-ish box on the left side of the screen. Clicking on any of the methods will expose the details (requirements) about that method thus:

Nice, huh?

The second file (that we’ve included in our source: (mywsdl.php)) is the WSDL file that defines our data structures that are used as either inputs, outputs, or both, to the exposed services. Another thing I like about SOAP and nuSOAP is that it introduces a layer of strong-typing to the PHP stack. You can save a bit of debugging time by requiring that you call a method with EXACTLY this and return EXACTLY that. Anything else tends to generate a system-level error:

1
2
3
4

<pre>[Thu Sep 22 14:36:59 2011] [error] [client ::1] PHP Fatal error: Call to a member function addComplexType() on a non-object in /htdocs/LL2/trunk/services/mywsdl.php on line 9
[Thu Sep 22 14:36:59 2011] [error] [client ::1] PHP Stack trace:
[Thu Sep 22 14:36:59 2011] [error] [client ::1] PHP 1. {main}() /htdocs/LL2/trunk/services/ll2wsdl.php:0</pre>
<pre>

This error message, from the apache error log, is somewhat obfuscated in it's meaning. I attempted to return only the string, by itself, instead of returning the array (of two elements) that I had told nuSOAP I would return for this service. This error was generated because the types (between the code and the WSDL) of the return variable (structure) did not exactly match.

If you've only ever coded in a loosely-typed language, like PHP, than this part of SOAP is going to be a bit of a ... transition ... for you. When we say that something, be it a variable, function, or exposed service, is strongly typed, we're declaring the type of that object and, if the type of the object during run-time does not match, then SOAP will force PHP to throw a fatal as shown in the error log snippet above.

Keep this in-mind as you develop exposed services that are increasingly complex. Since the error messages tend to point you at your code, at the point of failure, it's easy to forget that that the requirements of the underpinnings (in this case, the WSDL), are the root cause of your PHP fatals.

That being said, let's take a look at the WSDL for our ping service:

1
2
3
4
5
6
7
8
9
10
11

<pre><?php
/**
* WDSL control structures
*
* initially, while in dev, this will be one large file but, later, as the product
* matures, the plan will be to break out the WSDL files into associative files based
* on the object class being defined.
*/
$server->wsdl->addComplexType('aryReturn', 'complexType', 'struct', 'all', '',
array('status' => array('name' => 'status', 'type' => 'xsd:boolean'),
'data' => array('name' => 'data', 'type' => 'xsd:string')));</pre>

We're invoking the nuSOAP method addComplexType to define a structure to the WSDL in our Table Name Space (tns). To do this, we first define the name of the structure that we're going to use: aryReturn and then we define the composition of that structure.

The declaration for this looks a lot like a standard PHP declaration for an array with the exception of the XSD (XML Schema Definition) appended at the end of each element's declaration. (See the links I embedded above for explanations and examples of valid XSD.)

XSD provides part of the strongly-typed concept for our structure elements. We're telling nuSOAP to expect a variable structure containing these named elements of this type.

What we have, then, is an associative array with two elements: 'status' and 'data'. $aryReturn['status'] and $aryReturn['data'] and they're of type BOOL and STRING respectively.

Note, finally, that this variable structure isn't confined to single-use. Once we've declared it within our tns, it's available to any exposed service where it's needed. This is the model for my common error structure -- the boolean indicates success or fail on some service operation and the data component contains the relative diagnostic information.

The third and final file we're including into the server source is the code for the exposed service. This is where you write the function handlers for your services. Since you've already defined the input parameters, and the return types for the ping service, there's very little left to do.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<pre><?php
/**
* ping
*
* service that confirms server availability
*
* input: any string
*
* output: reformatted string: "Rcvd: {string} (charcount{string})"
*
* @param string $testString
* @return string
*/
function ping($testString = '') {
return(array('status' => true, 'data' => 'Rcvd: ' . $testString . '(' . strlen($testString) . ')'));
}</pre>

Note the following in the code for our exposed service:

our exposed method is named ping because that's how we registered the service (myServiceRegistrations.php)
we're providing a default type-cast for the input param of string in case the service is invoked without input params.
we're returning BOOL true and prepending "Rcvd: " to the received string, and appending a character count to prove that the service successfully responded to the client's request.
the return structure exactly matches the WSDL declaration: the name of the array elements, and the element types.

If you've correctly installed and referenced (within your PHP) the nuSOAP libraries, then you should be able to load the url of the new server source file into your web browser to see the nuSOAP-generated documentation for your new web services. Click on the WSDL service function: ping to see a detailed description of the function.

If you're using IE, then clicking on the WSDL link will return the XML. If you're using Firefox, Chrome or other browsers, clicking on WSDL will display the generated XML for your service.

Now that the server is working on it's own, it remains fairly useless until we can get a client to connect to it invoke it's methods. Let's work on the client next...

The Web-Services Client

The web services client application will also be written in PHP.

The web client is an application that connects to remote server using the http port 80. To do so, you'll need the client to be aware of certain bits of information that may, or may not, be required to access the remote server.

In our client, we're not going to require remote authentication -- but I'll take a quick aside andexplain how you would include this, client-side, if your server required .htaccess authentication.

nuSOAP has a client method called setCredentials which allows you to specify your .htaccess username and password and the authentication schema. It's a single line of code which is normally used to require not only clients to login to access your API, but, once identified, you can limit the set of exposed methods available to individual clients or groups.

For example, if you have a product you've developed in-house, then you'd want full-access for your front-end web/applications servers. Your PM later decides to open a subset of the API to the general public and a subscription-based set of exposed methods in order to monetize your product. Finally, the PM also wants to "white-box" the product so that other companies can use it but with their branding and access to isolated or discrete data sets.

What you'd end-up with is several levels of client access to your web services. Implementation of limiting exposed services would be handled server-side but it would be based on your client's authentication and possibly the subject of a future tutorial...

So, to the client-side code: (name this file: apiTestClient.php)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<pre><?php
// Pull in the NuSOAP code
require_once('./nuSOAP/nusoap.php');
$proxyhost = isset($_POST['proxyhost']) ? $_POST['proxyhost'] : '';
$proxyport = isset($_POST['proxyport']) ? $_POST['proxyport'] : '';
$proxyusername = isset($_POST['proxyusername']) ? $_POST['proxyusername'] : '';
$proxypassword = isset($_POST['proxypassword']) ? $_POST['proxypassword'] : '';
$useCURL = isset($_POST['usecurl']) ? $_POST['usecurl'] : '0';
$client = new nusoap_client('http://{YOURSERVERURLHERE}/index.php', false, $proxyhost, $proxyport, $proxyusername, $proxypassword);
$err = $client->getError();
if ($err) {
echo '<h2>Constructor error</h2><pre>' . $err . '</pre>';
}
$client->setUseCurl($useCURL);
$client->useHTTPPersistentConnection();
// Call the SOAP method
$result = $client->call('ping', array('testString' => 'Argle'), 'http://localhost');
// Display the result
if (!$result) {
echo "service returned false";
} else {
print_r($result);
}
unset($client);</pre>
<pre>?></pre>

The first thing we do in our client-side code is to include the nuSOAP libraries.

The next five lines of code read from the local POST environment, testing if you've established a proxy for your web-services server and, if so, populating the proxy variables.

The next line instantiates a nuSOAP client and associates it with our remote server. Change "YOURSERVERURLHERE" to the name of your apache web server URL where you have the server side code installed. (e.g.: localhost, myserver.com, etc.)

Note the name of the function call: newsoap_client()...as opposed to using the function soapclient(). This function name is legacy-compatible with PHP 5.0's instantiation call: new soapclient() - the PHP SOAP extension uses the same instantiation function name as the nuSOAP library. If you have both installed, (PHP 5.0 SOAP extension, and the nuSOAP libraries), executing the client will return errors as you've overloaded the soapclient() function. (You're calling the PHP SOAP function with the nuSOAP function parameters.) Rename the soapclient() function to the back-compatible function: newsoap_client().

The next two lines tell the nuSOAP client to useCurl, when possible and if previously saved and, if possible, to use HTTP persistent connections.

Next, we're going to consume the web-services from the server by making a call to the nuSOAP method: call(). The arguments to this method are:

the name of the service being consumed (ping)
the input string (note: all inputs must be passed as arrays!)
the namespace URI (optional: WSDL can override)

Store the results of the web-services to the aptly-named variable $results and evaluate it upon return. If the client call was not successful, then display an error message.

If the client call was successful, then display the contents of the returned array.

Note that you can run this client code from either a browser using the "file://" option or, if the client source code is accessible to apache, then you can display using a browser.

When I run this client-side software in the browser, I get displayed back:

Array ( [status] => 1 [data] => Rcvd: Argle(5) )

So, how do we know that the client went out and successfully returned from the server with the data? Simple - in the client source, you will not find the literal "Rcvd:" anywhere in the source. This data was supplied by the server-side function and returned back to the client. It's a simple example, but it provides proof-of-concept that we're successfully able to connect to a remote web-server and return data created on the remote server back to the client program.

Let's wrap this up...

Summary:

This tutorial (hopefully) explained what web-services are, and provided you with a practical example of a consumable service: ping(). Such a service would normally be invoked as a means of testing server availability.

We created a web-services server file using the nuSOAP library by defining a complex-structure (an associative array) and registering a method with the nuSOAP server. The method takes an input parameter which, although it's only a single input parameter, must be built and passed as an array construct to the server method. Next, we showed that by loading the server source into a browser, we learned the nuSOAP provides built-in documentation for your web-services structures and methods. Which is a very nice-to-have when you're creating your developer documentation! Next we created the web-services client source code file which connected to our remote server and invoked the server's method: hellow(). If all worked correctly, you displayed the string returned from the remote server within your browser window.

In the next installment, I'll cover the web-services server-side of this business and we'll see how to create the various methods for accessing a mySQL database, complex structures as input and output parameters to those methods, and general debugging techniques.

Thank-you for your patience - I hope this article helped you.

September 26, 2011

Don't miss a single post! Subscribe to my RSS feed

Press My Buttons !

Posted by : Micheal Shallop | Leave a Comment |

Waaaaake-up! Hello? Lion? You awake? WAKE-UP!

Posted by : Micheal Shallop Posted on : 10-09-2011

(No Ratings Yet)

Loading ...

Category : Rant, WTF

Tags: deep, disk, keyboard, light, lion, mac, mouse, nvram, os, permissions, power, pram, saver, saving, settings, sleep, up, usb, wake, wired, x

Oh, Apple. What did you do now?

It’s one thing to introduce broken (or bent) functionality in an upgrade release. It’s quite another to break (or bend) existing functionality in the same upgrade.

I really like Lion so far. What I thought I would miss, I don’t, and I’ve already become dependent on several of the base features that the upgrade offers.

And, hey, Microsoft (you big wad o’ suck) take note: a major update for $30 that I can install on all of my machines! And I don’t have to pay attention to see if it’s ultimate home premium 64, too!

(aside: I’m more pissed that usual at Microsuck. Earlier, using Bootcamp, I was playing Rift and I noticed that performance was lagging badly. To the point where I just decided to log-out and get some work done. After logging, I see that my tx/rx light on the dsl modem is solid. During shut-down, I see the usual dire-imprecations and deadly warning spew that pops when you update a Microsuck in-progress system update download.

WTF? I explicitly turned off the “feature” of independent updates in favor of only-update-when-I-tell-you option. You know, the way real operating systems do it. Apparently this setting means jack-shit as the crapware decided, again and on it’s own, to go out and download god knows what from the ‘net. Pure and unadulterated hubris.

Now I don’t mind the constant virus updates — I deleted three security exceptions from the Windows box today alone. But this constant updating without my permission really is pushing it. You confirm everything I want to do, concerning downloaded content, several times. But true to the “do as I say not as I do” philosophy of this bloatware, Windows continues to ignore user selections and configurations and just farts and whistles it’s way through a continuous stream of critical updates. Pure crapware.

Wanna end the wars in Iraq and Afghanistan? Send them free copies of Windows to install on all their military infrastructure. War will be over in a week, guaranteed.)

That was a long “aside”. Or rant. Or some factual observations. Whatever.

Anyway, back to a real operating system that not only let’s you get real-work done, but also listens, remembers, and then doesn’t ignore your configuration settings…

I’ve been having problems with my Lion installation not waking from deep sleep. I define two levels of sleep. One is light-sleep: where the computer’s screen saver kicks-in, and a simple mouse-twitch brings it back. The other is deep sleep: this would be when you explicitly put the computer to sleep, or your power management settings kick in.

What I’ve been experiencing has been happening either on weekend-mornings, or in the evenings when I get home from work. I sit down at the computer and poke the shift key, twitch the mouse, tap the space bar and … nothing. Repeat shit-key poke, mouse twitching, space bar tapping. … Still nothing.

I poke the caps-lock key. … No light. This is not good.

Both my keyboard and my mouse are wired USB peripherals. So I dis(re)connect the devices from the hub and, again, twitch the mouse, poke the cap-lock key and … black screen. There is no power indicator on the new 27″ iMacs. So I have no idea what state the computer thinks it’s in. Time for some drastics.

I tap the power button. This is usually enough, on my MacBook Pro, to jog it awake but, on my iMac…nothing.

Eventually, frustration wins out and I do a hard-reset by holding down the power key until it powers off and then I reboot.

Goddamnit.

I have a three support contract with Apple on this desktop but I’ll be damned if I’m going to call them to confess that I’ve no idea on how to wake-up my desktop from sleep. So, I google it.

I found this article, which explains how to reset the PRAM and NVRAM on your iMac because, you know, batteries get old and flash memory gets stupid over time. So I follow the steps and, when the computer restarts, it’s definitely brighter. (I’m not that good of a touch typist and I tend to inadvertently do things to both the brightness and volume controls…)

But, the next day when I get home from work, the computer is back in Rainman mode and I have to power-down to bring it back.

So I google it again, and this time I see a post on a mac-forum that blames the problem on disk permissions. Sure. Why not? So I run verify disk and, lo’! I have a bunch of crap that gets re-perm’d.

Still not going to call Apple.

I’m writing this article and I guess I’ll see what happens the next time I try to roust the machine from deep-sleep. I’m pretty confident that it’s going to fail and, if it does, then I’ll log a call to tech support.

In the meantime, if any of you have suggestions, I’m open…

Don't miss a single post! Subscribe to my RSS feed

Press My Buttons !

Posted by : Micheal Shallop | Leave a Comment |

X11Forwarding from CentOS 6 Linux to Mac OS X Lion via SSH

Posted by : Micheal Shallop Posted on : 03-09-2011

(No Ratings Yet)

Loading ...

Category : Technical

Tags: centos, centos6, display, forwarding, gnome, linux, lion, mac, os, remote, ssh, technical, tutorial, x, x11

In my previous post, I wrote about getting gpass (a password manager for the gnome desktop) compiled from source and running on our CentOS 6 platform. The screenie I took of the welcome screen was a mac-i-fied version.

I had configured my Linux machine to support X11 port-forwarding over a secure shell. It was surprisingly quick and easy to set-up and execute.

I wanted to remote-display the gpass window to my Mac OS X Lion desktop because I needed to transfer passwords from my 1Password application (running on Lion) to my gpass (Linux) program. Some of the passwords are pretty gnarly so the only way I can guarantee transferring data without making typos was to set-up a copy-paste-friendly environment.

One quick caveat. I’ve noticed that, when I terminate an X11 program from my Lion shell, I can no longer use that shell to initialize another X11 applet. I need to exit and re-start the terminal. If you know of the work-around for this, please leave a comment/reply to this post.

For all the following commands, it is assumed you have sudo privileges on your Linux system.

The first step I took was to edit the /etc/ssh/ssh_config file. At the end of the file, past the comments, there is a section labeled:

Host *
…
ForwardX11Trusted yes
X11 Forwarding yes
…

Make sure that you have those two lines, uncommented and present, in your configuration.

Next, (re)start your sshd server:

# /etc/init.d/sshd restart
Stopping sshd: [ FAILED ]
Generating SSH1 RSA host key: [ OK ]
Generating SSH2 RSA host key: [ OK   ]
Generating SSH2 DSA host key:   [ OK   ]
Starting sshd: [ OK   ]

In case you’re curious, the FAILED message in the first line of output was generated because I didn’t already have sshd running on my system.

My machines run on a 192.168 subnet behind two firewalls – the firewall on my DSL modem, and the firewall on my multi-port router. Normally, I’m not too concerned about the security of my individual machines. (e.g.: I’m not running a software firewall on my Mac or my Linux server.) My subnet is DHCP-served by my router and the router is on it’s own subnet DHCP-served by the dsl router/modem.

I need to obtain the current IP address of my linux server which I do so my running the ipconfig command.

Next, I switch over to my Mac and open a terminal — within the terminal, I enter:

iMac:~ mike$ ssh -X 192.168.0.6
The authenticity of host '192.168.0.6 (192.168.0.6)' can't be established.
RSA key fingerprint is f9:04:2d:0e:70:3d:a7:8f:92:c0:02:69:8c:f2:e6:51.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.6' (RSA) to the list of known hosts.
mike@192.168.0.6's password:
whassup?
/usr/bin/xauth: creating new authority file /home/mike/.Xauthority
[mike@codeMonkey ~]$

At the command prompt, I now only have to enter whatever X11 command and that program will be displayed on my Mac Desktop. I can even open and start an entire desktop session. I could – but I won’t — my Linux server only has 2gB of Ram…

Instead, I’ll open a gnome-terminal. So, at the prompt, I simply type: gnome-terminal and I get the gnome-terminal to appear on my desktop:

That’s pretty much all there is to it, as far as I could tell. Eazy-peezy.

One last note — once you have a terminal running on your Lion desktop, then any X11 commands, such as gpass, you enter will all be displayed on your Lion desktop. This circumvents the one-terminal-one-applet restriction I mentioned at the top of this article.

That’s pretty much it for this article — hope this helps!

Don't miss a single post! Subscribe to my RSS feed

Press My Buttons !

Posted by : Micheal Shallop | Leave a Comment |

Installing gpass on CentOS 6 Linux

Posted by : Micheal Shallop Posted on : 03-09-2011

(No Ratings Yet)

Loading ...

Category : Technical

Tags: 1password, centos, development, epel, gpass, install, linux, mcrypt, mhash, repository, technical, tutorial, yum

Over the last year I have become utterly dependent on a product called 1Password by Agile Bits software. For those of you that are unfamiliar with this software, 1Password is a multi-platform program that manages all your passwords, in additional to other sensitive information, in an easy-to-use interface.

Originally written for the Mac, the software is now offered on iPad, iPod, ‘droid, and Windows machines. I have it installed on all available platforms. While initially bemoaning the cost of the product – it’s not cheap – I’ve come to depend on it for all of password storage, my software license management, and even the credit-card information for the card I use for online purchases and subscriptions.

Quick aside and then I’ll cease the fanboi gushing: my favorite feature of the program is the password generator. I can custom-tailor a password to be as obnoxiously long, and obfuscated, as I need and I don’t ever, ever, have to type it in when challenged. Passwords are simply copy-pasted from the 1Password program, or you can use the embedded 1-click feature functionality of the support extensions available for all browsers.

My only complaint with 1Password is the lack of Linux support. Since I’m using Linux as my LAMP development platform while at-home, I need a comparable password manager. I know I won’t have all of the slick features of 1Password, but at least I’ll be able to copy-paste long, obfuscated, passwords from the password manager into my Linux desktop applications.

So, let’s get started!

There’s some good tutorials already available on the ‘net about doing just this – however, none I found were exactly right and, following those tutorials, I did run into several side issues. I’ll cover all those issues here so that your installation will be seamless.

Operating System: CentOS 6 Linux
Desktop GUI: Gnome
gPass version: 0.5.1
EPEL repository: 6.5

Download the gpass source into your “Downloads” directory and unpack the tarball:

wget http://projects.netlab.jp/gpass/release/gpass-0.5.1.tar.gz

tar xvzf gpass-0.5.1.tar.gz

cd gpass-0.5.1

I based my initial install of gpass from the UnixCraft blog post here. (In the tutorial, they omitted the arguments to the tar command to un-tar the tarball that creates the gpass source directory.)

In step 1, the blog asks you to do a group install of the development tools and, secondly, install the gnome-ui, mhash, and mcrypt development libraries. The second step failed for me following the successful install of the gnome-ui as my stock yum configuration was unable to locate either the mhash or the mcrypt packages.

After googling the issue, I determined that I needed to at the EPEL repository to my yum configuration. It’s common to have several repositories in your yum catalog. You’ll add additional repositories by establishing configuration files in /etc/yum.repos.d/.

Setting up the EPEL repository is pretty easy as they’ve created an rpm just for this purpose. Make sure you have sudo privileges on your account and enter the following commands: (I’m currently in the “Downloads” directory in my $HOME.)

wget http://download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm
...
rpm -Uvh epel-release-6-5.noarch.rpm

Side note: I’m aware when I’m reading how-to’s on other sites that reference software versions that said versions may not always be the current, and most stable, release available today. I always check the repository, using a browser, before downloading to ensure I’m obtaining the latest version.

Once the rpm is installed, you’ll need to edit the repository file. Again, using sudo, edit the /etc/yum.repos.d/epel.repo file and in the EPEL repository section, add the line: priority=3 at the end of the section.

I’m now ready to install the mhash and mcrypt packages, obtaining them from the Redhat EPEL repository. Again, assuming sudo privileges:

# yum install libmcrypt-devel
# yum install mhash-devel

From this point, you need merely to follow the instructions in the UnixCraft blog I linked-to above, but here are the steps to finish the installation. Again, assuming you’ve changed-directory to the gpass source:

./configure

./make

./make install

At this point, as long as you’ve not seen any error messages in your output, your gpass program is ready to use. Test by typing gpass at the command line — you should see the gpass window pop-up on your desktop:

In the screen-shot to the right, those of you that are past your second cup of coffee may have noticed that my gpass window looks suspiciously like a Mac OS X version.

I am running the gpass application on my Linux server, but I am serving the display to Mac OS X Lion desktop. I set-up the configuration to do this for two reasons.

to capture and display screenies
to copy paste data from my native Mac 1Password application into my Linux gpass application. I do NOT want to retype some of those passwords…

That’s pretty much it. I leave the exploration and use of gpass up to you. I’ll do a follow-up tutorial quick-post on how-to set-up XForwarding on Linux to your remote desktop (Mac) via secure shell.

Thanks for reading – hope this helps!

Don't miss a single post! Subscribe to my RSS feed

Press My Buttons !

Posted by : Micheal Shallop | Leave a Comment |

Featured Posts

Subscribe

Web Services with PHP & nuSoap – Part 1.1

Introduction

The Web-Services Server

The Web-Services Client

Summary:

Waaaaake-up! Hello? Lion? You awake? WAKE-UP!

X11Forwarding from CentOS 6 Linux to Mac OS X Lion via SSH

Installing gpass on CentOS 6 Linux

Login

Pages

San Ysido Weather

Recent Twitage

September 2011
S	M	T	W	T	F	S
« Aug				Oct »
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30