Alex,
We use the API on 4.1 and haven't had any problems. We're using the
HTTPS POST method from perl.
my $CCA_Manager = 'https://ccamanager/admin/cisco_api.jsp';
my $ua = LWP::UserAgent->new;
$ua->agent(VERSION);
# Create a request
my $req = POST $CCA_Manager,
[ admin => $CCA_Admin,
passwd => $CCA_Passwd,
op => 'addmac',
type => 'userole',
role => $role,
mac => $mac,
desc => $descr
];
# Pass request to the user agent and get a response back
my $res = $ua->request($req);
# Check the outcome of the response
if ($res->is_success) {
if ( Check_CCA_Error($res->content) ) {
return 1;
} else {
return;
}
Let me know if you want me to try anything in particular.
Michael Grinnell
Network Security Administrator
The American University
On Feb 7, 2007, at 11:42 AM, Lanstein, Alex C wrote:
> Is anyone using the API on 4.1, using curl or otherwise? And has
> it working?
>
> Somewhere between 4.0 and 4.1 (we're on 4.0.4 and its not there),
> cisco decided it would be a good idea to add a rewrite for /admin
> to [R] to /admin/main.jsp. Sounds cool, makes it a little easier
> from the web (can just go to https://cam/admin and it will work),
> blah blah blah, but it breaks the api from what i can tell.
>
> Either when doing a straight HTTPS POST by hand, or by using cURL,
> I get the following header output:
>
> HTTP/1.1 200 OK Date: Wed, 07 Feb 2007 16:23:29 GMT Server: Apache
> Set-Cookie: JSESSIONID=D43B996........868D99FE87; Path=/admin;
> Secure Content-Length: 56 Content-Type: text/html;charset=ISO-8859-1
>
> So clearly, apache is recognizing this as /admin, and not /admin/
> cisco_api.jsp, and thus redirects the post to main.jsp. That's why
> all you guys see the login box when you try to use the api. it's
> actually main.jsp.
>
> Prem says that it's not an issue, as from the command line he seems
> to be able to get it to work. I'm not on 4.1...so if there's
> someone that is and is having api issues, if you could try:
>
> curl -k -d op=addmac -d mac=00:01:02:03:04:05 -d admin=admin -d
> passwd=cisco123 https://your_cam/admin/cisco_api.jsp > out
>
> then just cat out and copy the results in here, I'd appreciate it.
> the terminal may be a little screwly if you just try to do it with
> curl to stdout instead of redirecting it.
>
> if you're using trying to use the api, you can either copy the api
> to a different directory (say, /wlan/), or edit ssl.conf and remove
> the rewrite, that will fix it. If it were me I would just copy the
> api to a different directory and POST to there
> Regards,
>
> Alex Lanstein
> Senior Software Engineer, Transitional Data Services
> Help Desk/Network Junkie, Connecticut College
> Chief Coffee Drinker, LBCCHosting
> 860-625-4277
> [log in to unmask]
>
> ________________________________
>
> From: Cisco Clean Access Users and Administrators on behalf of Sean
> A. Thomas
> Sent: Wed 2/7/2007 9:50 AM
> To: [log in to unmask]
> Subject: Re: US DST Timezone Changes, CSCsg44268, /etc/localtime?
>
>
>
> My Unix admin team suggested that I run the command:
>
> /usr/sbin/zdump -v EST5DST | grep 2007
>
> I did so on my cam's and cas's (as well as my local linux boxen)
> and all
> checked out. I'm not sure which is the "most correct" way to check.
>
> Sean
>
>
> ________________________________
>
> Sean A. Thomas, MCP, RHCT
> Academic Systems Administrator
> Embry-Riddle Aeronautical University
> [log in to unmask]
> 386-226-6193 - Office
>
> You asked for it...learn more about ERNIE at http://it.erau.edu/ernie.
>
> -----Original Message-----
> From: Cisco Clean Access Users and Administrators
> [mailto:[log in to unmask]] On Behalf Of Mike Diggins
> Sent: Tuesday, February 06, 2007 5:24 PM
> To: [log in to unmask]
> Subject: Re: US DST Timezone Changes, CSCsg44268, /etc/localtime?
>
> I've been using this command to check:
>
> zdump -v Canada/Eastern |grep 2007
>
> which returns the correct DST settings on my CAM and CAS. Your command
> returns the correct settings on my CAM, but the old DST settings on
> my CAS.
> Which is right?
>
> -Mike
>
>
> On Tue, 6 Feb 2007, Bruce A. Locke wrote:
>
>> I was poking around our CCA Manager server to see if the version of
>> Fedora Linux that it uses was updated for the upcoming changes to
>> Daylight Savings Time in the US.
>>
>> The output of "zdump -v /etc/localtime | grep 2007" on our system
>> shows:
>>
>> /etc/localtime Sun Apr 1 06:59:59 2007 UTC = Sun Apr 1 01:59:59
>> 2007 EST isdst=0 gmtoff=-18000 /etc/localtime Sun Apr 1 07:00:00
>> 2007 UTC = Sun Apr 1 03:00:00 2007 EDT isdst=1 gmtoff=-14400
>> /etc/localtime Sun Oct 28 05:59:59 2007 UTC = Sun Oct 28 01:59:59
>> 2007 EDT isdst=1 gmtoff=-14400 /etc/localtime Sun Oct 28 06:00:00
>> 2007 UTC = Sun Oct 28 01:00:00 2007 EST isdst=0 gmtoff=-18000
>>
>> The file does not contain the DST update. But the copy of the
>> New_York timezone file in /usr/share/zoneinfo/America/New_York does:
>>
>> /usr/share/zoneinfo/America/New_York Sun Mar 11 06:59:59 2007 UTC =
>> Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
>> /usr/share/zoneinfo/America/New_York Sun Mar 11 07:00:00 2007 UTC =
>> Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
>> /usr/share/zoneinfo/America/New_York Sun Nov 4 05:59:59 2007 UTC =
>> Sun Nov 4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
>> /usr/share/zoneinfo/America/New_York Sun Nov 4 06:00:00 2007 UTC =
>> Sun Nov 4 01:00:00 2007 EST isdst=0 gmtoff=-18000
>>
>> The timestamp on /etc/localtime matches the day we did the
>> destructive
>> reinstall up to 3.6.0(?) which was on December 29, 2005. The
>> timestamp for /usr/share/zoneinfo/America/New_York was on May 11,
>> 2006.
>>
>> It looks like the tzdata package was updated somewhere around CCA
>> 4.0.4 and the update did not contain the corresponding glibc-common
>> upgrade from Fedora. The glibc-common package usually has a trigger
>> that updates /etc/localtime if tzdata is also updated. So unless
>> such
>> a trigger was added to tzdata in Cisco's forked version or put in the
>> update script for CCA then /etc/localtime will never be updated. I
>> don't see such an update in their script but I could have very well
>> missed it.
>>
>> Is this a known issue? The resolved caveats list for 4.0.3.3 shows
>> CSCsg44268 but shouldn't /etc/localtime be updated for that? Has
>> anyone else seen this on their systems? It may very well be a fluke
>> with our local environment but I just want to be sure.
>>
>> Thanks.
>>
>> --
>> Bruce A. Locke
>> [log in to unmask]
>> HAB 50 - (845) 257-3809
>>
>> Network Administrator
>> Computer Services
>> State University of New York at New Paltz
>>
>
>
> _________________________________________
>
> Mike Diggins Voice: 905.525.9140 Ext.
> 27471
> Network Analyst, Enterprise Networks FAX: 905.528.3773
> University Technology Services E-Mail: [log in to unmask]
> McMaster University, Hamilton, Ontario
|
