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
|
