:(

I’ve spent the past three days troubleshooting a bug in the PHP SDK itself.

Once I had my prototype working I started to add some error checking and logging. I quickly discovered that calls to closeSession() were failing, but they were failing from within the SDK itself, never making it to the actual appliance. I switched to termSession() which was also failing but at least the SDK was actually passing the API request to the appliance and I could see it failing in a packet trace. The SDK would return “Paramater [SID] must be provided” with closeSession() or “Invalid session ID” with termSession().

The PHP SDK formulates the REST calls to the A10 ADC, however, in this case the PHP SDK wasn’t formulating the calls properly when using termSession() and wasn’t sending anything when using closeSession() because it was likely failing an internal parameter check.

Here’s the example below when I called $axapi->sessionTerm();

http://10.1.1.1/services/rest/V2/?method=session.close&sid=d058ce0c98a30674dfdc4e39bbfcef

Here’s what I eventually discovered the REST API actually expects;

http://10.1.1.1/services/rest/V2/?method=session.close&session_id=d058ce0c98a30674dfdc4e39bbfcef

I’m not sure how many people are using the PHP SDK but I’d guess not too many. I had to hack the files /include/fucntions_1.php and /include/functions_2.php so that they passed the parameter name of session_id and not sid.

[mfm@centos includes]# diff functions_1.php functions_1.php-orig
6c6
<       'close' =>array('xpath' => 'response', 'function' => 'session.close', 'request_method' => 'POST', 'params' => array('session_id' => array('required'))),
---
>       'close' =>array('xpath' => 'response', 'function' => 'session.close', 'request_method' => 'POST', 'params' => array('sid' => array('required'))),
411c411
< return $result; --- > return $result;
\ No newline at end of file


[mfm@centos includes]# diff functions_2.php functions_2.php-orig
7c7
<       'close' =>array('xpath' => '//response', 'function' => 'session.close', 'request_method' => 'POST','version' => 1, 'params' => array('session_id' => array('required'))),
---
>       'close' =>array('xpath' => '//response', 'function' => 'session.close', 'request_method' => 'POST','version' => 1, 'params' => array('sid' => array('required'))),
513c513
< return $result; --- > return $result;
\ No newline at end of file

With that change I’m no longer getting errors when trying to close the session and I can go back to actually writing useful code.

On another note it took me more than a few minutes to find the actual SDKs. There’s a few really tantalizing write-ups available on A10’s website but neither go into much detail and they both refer users to the other document which left me a loop – pardon the pun. I finally found the SDKs on the download side of the support website.

I hope to start posting some useful information around A10 now that they have a lot of visibility in my network.

Cheers!

In a subsequent comment Greg really hits on his point.. “We need APIs for device consistency, frameworks for validation and common actions. But above that we need platforms that solve big problems – scripting can only solve little problems. ”

I agree but for now we need to work with what we have available, and that’s no reason to stop scripting today. That said scripting is not a tool that’s going to solve every problem in IT. It might helpful for initial deployments, provisioning, backups, monitoring, testing, etc. but it’s rare that scripting will solve every problem. I personally employ a combination of commercial management solutions with scripting to achieve my goals. I’ve worked with the following methods and technologies: EXPECT/TCL, SNMP, PHP, PERL, XML, NETCONF. These all have their individual challenges but each can be used in their own fashion to help automate a task or process depending on the task or the vendor in question. If you need to-do something once or twice there’s no need for a script or automation, but if you are going to-do something daily or weekly across dozens or hundreds of assets then a script can be extremely helpful.

The point of writing a script is really two fold in my opinion, first to automate the task but more importantly to remove the human error element. I do a lot of my work in the wee morning hours when the eyes are bloodshot and the mind isn’t always as rested as it should be. It’s easy to make simple stupid mistakes repeating monotonous commands on dozens even hundreds of switches or routers. A script helps to actually do the work and it makes sure that I won’t accidentally blow something up, I’m really there just to monitor for problems or issues.

It should be no surprise that there’s effort required to maintain a script, it’s just like a commercial vendor maintaining a product. Here’s the changelog for a Perl script I maintained between 2003 and 2014  that utilized SNMP and TFTP against Avaya/Nortel, Cisco, Motorola/Symbol and HP gear. You can see some of the challenges that Greg referred to in his article;

# Changes:
#
#     May 04, 2011 (M.McNamara) added support for HP C-Class GbE2c and legacy P-Class GbE2
#                               thanks to Karol Perkowski for his code addition
#     Dec 28, 2010 (M.McNamara) added additional code to support ERS4500 being slow TFTP transfer
#     Dec 27, 2010 (M.McNamara) updated CISCO-PRODUCTS-MIB to cover ciscoCBS3120 blade
#     Dec 20, 2010 (M.McNamara) updated ASCII routine with OID s5AgSysAsciiConfigManualUpload
#     Aug 31, 2010 (M.McNamara) added routines to handle binary and ASCII data for Avaya ERS switches
#				also added code to keep 4 archive copies per device
#     Dec 02, 2009 (M.McNamara) cleaned up code added additional debug routines
#     Oct 23, 2008 (M.McNamara) added support for Motorola RFS7000 Wireless LAN Switch
#     Oct 22, 2008 (M.McNamara) added support for ASCII configuration files for Avaya ERS switches
#     Oct 10, 2008 (M.McNamara) added support for Cisco switches
#     Jan 22, 2008 (M.McNamara) added support for HP GbE2c (C-Class) switch
#     Apr 24, 2007 (M.McNamara) added support for WS5100 3.x software
#     Oct 24, 2006 (M.McNamara) added support for ERS1600 v2.1 release
#     Sep 29, 2006 (M.McNamara) added support for BayStack 470 PwR 48T
#     Oct 20, 2005 (M.McNamara) added support for Baystack 5510 24 port also added 
#				Ethernet Routing Switch (formerly Passport) 8600 code
#     Mar 01, 2005 (M.McNamara) incorporated a sub to check for the presence of the
#				proper filename on the TFTP server (/tftpboot) thereby 
#				eliminating the first script "readytftpbackup.pl"
#     Feb 25, 2005 (M.McNamara) added the ability to retry a failed backup
#     Jan 13, 2004 (M.McNamara) some minor bugs throughout code base
#     Jan 06, 2004 (M.McNamara) implemented a workaround for the Passport RAPID-CITY MIB 
#				> 3.2 problem, copied OIDs for Passport 1600 into 
#				 existing MIB along with required MIBS and added sub 
#				to handle 1600s
#     Jan 05, 2004 (M.McNamara) issues with SNMP MIB for Passport 8600 v3.3.4 is presenting
#				problems with the Net-SNMP perl modules and the old MIB 
#				cannot identify the newly added Passport 1600 switches.
#     Dec 11, 2003 (M.McNamara) resolved issue with Passport 8600 not backing up properly
#     Sep 17, 2003 (M.McNamara) added code to incorporate all BayStack switches into backup
#     Oct  1, 2003 (M.McNamara) added code to email status report to notify@acme.org
#				also added Perl script to weekly crontab

Will the scripts I write today be useless in two years, possibly but that’s pretty much the case with anything these days including your phone, your laptop, etc. While we wait for something else to come along the the scripts I write and maintain will be very helpful in making my job easier and making me more efficient.

Cheers!

PS: I’ve finally cleaned up the Scripting section of my blog, fixing all the broken links and updating all the code.