Downloads |
 Feedback
|
Table Of Contents
Cisco Application Extension Platform 1.6 Advanced Features Guide
Obtaining the Unrestricted Shell Add-on Package
Obtaining Unrestricted Shell Access
Packaging Tool (Non-interactive): Example
Specifying a Capabilities Category in the Development Authorization File
Capabilities Configuration File
@CCAPABILITIES: Context Capabilities
@BCAPABILITIES: System Capabilities
@MODULES: Loadable Kernel Modules
Loadable Kernel Module Support
Third Party Loadable Kernel Modules
LKM Verification and Troubleshooting
How to Build a Third Party LKM
Troubleshooting the Build of a Third Party LKM
Building Additional Kernel Modules
Cisco AXP Commands for Advanced Features
Cisco Application Extension Platform 1.6 Advanced Features Guide
This guide explains the advanced features of Cisco AXP for developers.
Use this document with other Cisco AXP documentation found under "Support" at: http://www.cisco.com/en/US/products/ps9701/index.html
Revised: 6/23/11, OL-21478-01Contents
•
Loadable Kernel Module Support
•
Unrestricted Shell Access
The unrestricted shell, available using Cisco AXP 1.1 and higher versions, allows root access for debugging, monitoring CPU usage, or obtaining virtual memory statistics.
To obtain unrestricted shell access for your application:
1.
2.
3.
To remove the debug shell add-on package, one option is to use the command software install clean to reinstall the Cisco AXP host OS package, and then reinstall all other required packages. For further details on these commands, refer to the relevant version of the Cisco AXP Command Reference Guides.
Obtaining the Unrestricted Shell Add-on Package
To obtain unrestricted shell access, the debug shell add-on package obtained from Cisco Developer Support must be installed on top of AXP.
To obtain the debug shell package:
Step 1
Step 2
Step 3
show license udi: ExampleIn this example, the command is run on VMware.
show license udiPID SN UDI---------------------------------------------------VME_APPRE-K9 -- 00:11:22:33:44:55Step 4
Step 5
Note
Obtaining Unrestricted Shell Access
To obtain unrestricted shell access:
Step 1
Step 2
show tech-support command in Cisco AXP EXEC mode to verify that the debug shell package has successfully installed.Verifying Debug Package Installation: Example
In this example the following output is displayed after you enter show software versions detail:
Name: Debug Shell built for <Customer Name> (1.5)Desc: Debug shell - not for use on production systemsid: 8c7ea828-82ad-455f-b8a8-9dd965ce4d1bType: (plug-in)Step 3
•
INFO AXP_debug_shell shll exec Debug shell access has been granted•
ERROR AXP_debug_shell shll exec Debug shell access has been deniedStep 4
show log name messages.log | include debug_shellCapabilities
Capabilities allow the following additional functions to be enabled for an application.
•
•
•
If an application has permission to a category it can access and configure all capabilities belonging to category.
To obtain permissions to a capabilities category, contact Cisco Developer Services. See the "Specifying a Capabilities Category in the Development Authorization File" section for further details. The development authorization file/bundle controls capabilities permissions.
You can use capabilities defined in the capabilities configuration file to relax certain restrictions in a virtual instance. Use a single host-level capability or kernel-level capability with one application in the system.
Note
There are three categories of capabilities:
•
•
•
Note
If you have permissions for a capability category, you can turn on any of the capabilities within that category. If you add a new capability to a category, the capability can be accessed by any existing applications that already have access to that category. This saves you from having to repackage a new development authorization file with your application.
During packaging of your application, specify the capabilities configuration file using parameter "cap-config".
Note
The following sections describe the capabilities configuration file, and the development authorization file as it relates to capabilities.
•
•
•
Packaging Tool (Non-interactive): Example
The following example shows how to specify the capabilities configuration file during packaging. To do this, the packaging tool pkg_build.sh is called in non-interactive mode.
The last argument in the call of pkg_build.sh is cap-config, which references the capabilities configuration file /capabilities.cfg. The capabilities configuration file is at the same level as the project source directory or file post-install.sh.
./pkg_build.sh --project-dir '/wsa/proj-cap' --dev-cert '/wsa/auth/cert/dev_certificate.sig' --dev-auth '/wsa/auth/cert/dev_authorization.sig' --private-key '/wsa/auth/cert/private.key' --name 'capdev' --version '1' --source-dir '/wsa/captest/bin/' --disk-limit '100M' --memory-limit '50M' --cpu-limit '1000' --postinstall '/post-install.sh' --cap-config '/capabilities.cfg'Specifying a Capabilities Category in the Development Authorization File
The development authorization file contains attributes to control the capabilities categories that are turned on/off. If a capability category is turned on, you can access the capabilities in the category. The attributes are: guest_admin, host_admin, and kernel_admin.
To obtain permission to a capabilities category for an application package, perform the following steps.
Step 1
Step 2
Step 3
Step 4
If your application is being repackaged as part of an upgrade and previously contained an older configuration file, permission to access old (previously granted) capabilities are removed and permission to access new capabilities are added. Therefore, before running the application, make sure that application commands using old capabilities are removed or blocked.
Capabilities Configuration File
Different capabilities are listed in sections of the capabilities configuration file. Each section begins with the "@" symbol.
Capabilities Configuration File: Example
The CCAPABILITIES section is the first section in this example configuration file, shown using the command cat. CCAPABILITIES are context capabilities. The module ip_tables.ko is a Cisco LKM, and module /mypath/to/module/my.ko is the name of the third-party LKM.
$ cat capabilities_file@CCAPABILITIES=UTSNAMERLIMITRAW_ICMPSYSLOGSECURE_MOUNT@FLAGS=FAKEINITVIRT_MEMVIRT_UPTIMEVIRT_CPU@BCAPABILITIES=SYS_NICENET_ADMINSYS_TIMEMKNODSYS_MODULESYS_ADMINSYS_CHROOT@DEVFS=/dev/loop0 b 7 0/dev/loop1 b 7 1/dev/loop2 b 7 2/dev/null c 1 3/dev/myown b 2 2@PROCFS=/proc/bus//proc/sys/vm/overcommit_memory 0/proc/sys/net/ipv4/ip_forward 0@MODULES=ip_tables.koiptable_filter.ko/mypath/to/module/my.koThe capabilities in the configuration file are explained in the following sections:
•
•
•
Note
@CCAPABILITIES: Context Capabilities
Context capabilities (ccaps) are guest-level capabilities, which apply to all processes within a virtual instance. One capability is defined per entry in the capabilities configuration file.
Example:
@CCAPABILITIES=UTSNAMEFor a list of supported context capabilities, see Table 1.
Note: The following ccaps are not supported by Cisco AXP:
•
•
@FLAGS: Context Flags
Context flags (cflags) apply to all processes within a virtual instance.
Example:
@FLAGS=FAKEINITVIRT_MEMFor a list of supported context flags, see Table 2.
Note: The following cflags are not supported in Cisco AXP:
•
•
•
•
•
•
•
•
•
•
@BCAPABILITIES: System Capabilities
System capabilities (bcaps) apply to all virtual instances in Cisco AXP.
Example:
@BCAPABILITIES=SYS_NICENET_ADMINFor a list of system capabilities supported in Cisco AXP, see Table 3.
Note
Table 3 @BCAPABILITIES: System Capabilities
0
0x00000001
CHOWN
In a system with the [_POSIX_CHOWN_RESTRICTED] option defined, this overrides the restriction of changing file ownership and group ownership.
1
0x00000002
DAC_OVERRIDE
Override all DAC access, including ACL execute access if [_POSIX_ACL] is defined. Excludes DAC access covered by CAP_LINUX_IMMUTABLE.
2
0x00000004
DAC_READ_SEARCH
Overrides all DAC restrictions regarding read and search on files and directories, including ACL restrictions if [_POSIX_ACL] is defined. Excludes DAC access covered by CAP_LINUX_IMMUTABLE.
3
0x00000008
FOWNER
Overrides all restrictions about allowed operations on files, where file owner ID must be equal to the user ID, except where CAP_FSETID is applicable. It does not override MAC and DAC restrictions.
4
0x00000010
FSETID
Overrides the following restrictions that the effective user ID must match the file owner ID when setting the S_ISUID and S_ISGID bits on that file; that the effective group ID (or one of the supplementary group IDs) must match the file owner ID when setting the S_ISGID bit on that file; that the S_ISUID and S_ISGID bits are cleared on successful return from chown(2) (not implemented).
5
0x00000020
KILL
Overrides the restriction that the real or effective user ID of a process sending a signal must match the real or effective user ID of the process receiving the signal.
6
0x00000040
SETGID
Allows setgid(2) manipulation.
Allows setgroups(2).
Allows forged gids on socket credentials passing.
7
0x00000080
SETUID
Allows set*uid(2) manipulation (including fsuid).
Allows forged pids on socket credentials passing.
8
0x00000100
SETPCAP
Transfer any capability in your permitted set to any pid, remove any capability in your permitted set from any pid.
9
0x00000200
LINUX_IMMUTABLE
Allow modification of S_IMMUTABLE and S_APPEND file attributes.
10
0x00000400
NET_BIND_SERVICE
Allows binding to TCP/UDP sockets below 1024.
Allows binding to ATM VCIs below 32.
11
0x00000800
NET_BROADCAST
Allow broadcasting, listen to multicast.
12
0x00001000
NET_ADMIN
Note: For further information on this capability, refert to the "NET_ADMIN Capability" section.
Allow interface configuration.
Allow administration of IP firewall, masquerading and accounting.
Allow setting debug option on sockets.
Allow modification of routing tables.
Allow setting arbitrary process / process group ownership on sockets.
Allow binding to any address for transparent proxying.
Allow setting TOS (type of service).
Allow setting promiscuous mode.
Allow clearing driver statistics.
Allow multicasting.
Allow read/write of device-specific registers.
Allow activation of ATM control sockets.
13
0x00002000
NET_RAW
Allow use of RAW sockets.
Allow use of PACKET sockets.
14
0x00004000
IPC_LOCK
Allow locking of shared memory segments.
Allow mlock and mlockall (which doesn't really have anything to do with IPC).
15
0x00008000
IPC_OWNER
Override IPC ownership checks.
17
0x00020000
SYS_RAWIO
Allow ioperm/iopl access.
Allow sending USB messages to any device via /proc/bus/usb.
19
0x00080000
SYS_PTRACE
Allow ptrace() of any process.
20
0x00100000
SYS_PACCT
Allow configuration of process accounting.
22
0x00400000
SYS_BOOT
Allow use of reboot().
23
0x00800000
SYS_NICE
Allow raising priority and setting priority on other (different UID) processes.
Allow use of FIFO and round-robin (realtime) scheduling on own processes and setting the scheduling algorithm used by another process.
Allow setting cpu affinity on other processes.
24
0x01000000
SYS_RESOURCE
Override resource limits. Set resource limits.
Override quota limits.
Override reserved space on ext2 file system.
Modify data journaling mode on ext3 file system (uses journaling resources).
Note
Override size restrictions on IPC message queues.
Allow more than 64hz interrupts from the real-time clock.
Override max number of consoles on console allocation.
Override max number of keymaps.
25
0x02000000
SYS_TIME
Allow manipulation of system clock.
Allow irix_stime on mips.
Allow setting the real-time clock.
26
0x04000000
SYS_TTY_CONFIG
Allow configuration of tty devices.
Allow vhangup() of tty.
28
0x10000000
LEASE
Allow taking of leases on files.
NET_ADMIN Capability
The NET_ADMIN capability allows:
•
•
Refer to the "NET_ADMIN Capabilities List" section. This shows a BCAPABILITY of NET_ADMIN, and flag CISCO_ADVANCED_NET_ADMIN.
Note
Note
Interface eth0 must be configured from the Cisco IOS router, not from the application.NET_ADMIN Capabilities List
@CISCO_FLAGS=CISCO_ADVANCED_NET_ADMIN@BCAPABILITIES=NET_ADMIN@MODULES=tun.ko@DEVFS: devfs
The @DEVFS section of the capabilities configuration file contains entries for each device node in the /dev file system. Data in each device node is written at packaging time.
Each devfs entry consists of the following four attributes, separated by a single space character:
<device name> <device type> <major number> <minor number>Each attribute is described in Table 4.
Example:
In the following example, /dev/loop0 is a loopback disk device.
@DEVFS=/dev/loop0 b 7 0/dev/loop1 b 7 1...The /dev file must exist at the specified location at installation time. Errors are logged to /var/log/messages.log.
@PROCFS: procfs
The @PROCFS section of the capabilities configuration file contains /proc file system entries. Each entry represents a directory that can be unhidden at runtime and viewed by an application in a virtual instance. Applications can make changes to writable entries in the /proc file system, typically in the /proc/sys directory.
This host-level capability is exposed to the guest OS, and visible in all virtual instances. For detailed information about available /proc file system entries, contact Cisco Developer Support.
Each entry in @PROCFS section of the capabilities configuration file may use * (the wildcard character) for pattern matching.
Each entry in the configuration file starts with "/proc/".
If an entry contains a pathname ending in "/", files underneath are unhidden recursively. For example, the "/proc/bus/" entry in the @PROCFS example below means that files in sub-directories such as /proc/bus/a /proc/bus/b are unhidden.
Example
@PROCFS=/proc/vmstat/proc/bus//proc/sys/overcommit_memory 2...If an entry ends in *, this indicates that all directories on the same level are unhidden. For example, /proc/bus* indicates with names such as /proc/busa or /proc/busb.
Each valid /proc entry is added to the virtual instance.
Modifying a /proc Entry
A parameter in a writable /proc entry can be modified by including a value after the parameter. The value is separated from the parameter by a single space character.
Example
In the following example, the value of 2 modifies the /proc entry. The existence of /proc/sys/overcommit_memory is not checked, and the value of "2" is not validated.
/proc/sys/overcommit_memory 2There is no arbitration of conflicts arising from different virtual instances writing to the same /proc entry. Any errors are logged to /var/log/messages.log.
Note
@MODULES: Loadable Kernel Modules
The @MODULES section of the capabilities configuration file lists the loadable kernel modules (full pathname), to be installed, in order. If just the value of ".ko" is supplied (without no pathname), then the module is treated as a Cisco-provided kernel module.
Example
@MODULES=/mypath/to/module/my.ko ? third-party module/mypath/to/module2/my2.ko ? third-party moduleip_tables.ko ? Cisco provided ko/mypath/to/module3/my3.ko ? third-party moduleA third-party kernel module entry includes the full path name of the module. (Symbolic links or soft links to module names are not supported.)
For non-Cisco provided modules, the full pathname must indicate the location of the module. The path must be absolute (non-relative).
During installation, no checks are performed. However, on system boot up, all the modules are added, and any errors are logged to /var/log/messages.log.
Viewing Kernel Capabilities
Use the show tech-support command in Cisco AXP application service EXEC mode to view kernel capabilities that were set up on the service module.
show tech-support: Example
se-10-0-0-0(exec-guest-application)> show tech-support | begin Capabilities------------------ Application Capabilities------------------System Capabilities:DAC_OVERRIDEDAC_READ_SEARCHFOWNERFSETIDKILLSETGIDSETUIDSETPCAPNET_ADMINContext Capabilities:UTSNAMERLIMITRAW_ICMPSYSLOGSECURE_MOUNTSECURE_REMOUNTBINARY_MOUNTQUOTA_CTLDev FS:/dev/null c 1 4/dev/mytest b 20 8/dev/loop0 b 7 0/dev/loop1 b 7 1Net Flags:Proc FS:/proc/test blah/proc/sys/net/ipv4/ip_forward 0Kernel Modules:cisco_module.ko/mymod/capture.koThe following capabilities have errors when applied:Proc FS: /proc/test blahKernel Modules: cisco_module.koThe following capabilities have errors during installation:System Capabilities: SYS_ADMINAdditional References
For further information on capabilities, see http://linux-vserver.org/Capabilities_and_Flags.
Loadable Kernel Module Support
Loadable kernel module (LKM) support on Cisco AXP is provided by Cisco, or a third-party.
. The following sections describe both Cisco and third-party LKMs
•
•
•
LKM Types
LKMs for Cisco AXP consist of the following types:
•
•
Cisco Loadable Kernel Modules
Cisco AXP supports Cisco-provided loadable kernel modules (Cisco LKMs). Cisco LKMs are in the Cisco AXP base image. To use the LKMs, you must first package the LKMs with your application. Your application needs to have host-level capability. Refer to the "Capabilities" section.
Specify the list of Cisco LKMs at packaging time in the @MODULES section of the capabilities configuration file.
Example
In this example, third-party LKMs mymodule.ko and mymodule2.ko are specified in the capabilities configuration file.
@MODULES=
ip_tables.ko
iptable_filter.ko
List of Cisco LKMs
•
•
•
•
•
Third Party Loadable Kernel Modules
Loadable Kernel Modules (LKMs), which are not provided by Cisco, are known as third-party LKMs. You can package third-party LKMs with your application if the application has a kernel-level capability. Refer to the "Capabilities" section.
During packaging, specify kernel modules in the "@MODULES" section of the capabilities configuration file.
Note
Example
In this example, third-party LKMs mymodule.ko and mymodule2.ko are specified in the capabilities configuration file.
@MODULES=
/my/path/to/module/mymodule.ko
/my/path/to/module/mymodule2.ko
The modules are copied to the application service module during installation. They are installed during startup after the application service module reloads. (Currently the application service module always reloads after an application is installed.)
When the system boots up, each kernel module is installed into the kernel, before the virtual instance starts. If a virtual instance is started and stopped, this does not affect any installed kernel modules.
If an application with kernel modules is uninstalled, the kernel modules are removed along with the contents of the virtual instance.
Upgrading Cisco AXPOS
If you are considering upgrading Cisco AXPOS to a higher version, determine if your kernel modules will continue to work after the new version of Cisco AXP is installed.
Installing the LKMs might fail if you have an old version of your kernel module that does not match the new version of the OS. Failures that occur during installation, are logged to the file /var/log/messages.log. If a failure occurs because of a kernel module: rebuild the kernel module using a newer version of the LKM SDK, repackage and upgrade the application.
Controlling LKMs at Runtime
If your application is packaged with a dependency on the application development package axp-app-dev.<product>.<version>.pkg and you have kernel-level capability, you can install or uninstall kernel modules with your application at runtime. In the test environment the LKMs are added or removed depending on the contents of the capabilities configuration file. This avoids having to repackage your application each time that you want to test a kernel module.
Note
To add or modify an LKM at runtime, perform the following steps:
Step 1
Step 2
Step 3
Enters application service mode.
Step 4
The virtual instance resets and the new LKMs are loaded.
LKM Verification and Troubleshooting
Use the following command to verify configurations or to troubleshoot:
show tech-support | begin Capabilities
Displays logs to help determine which modules are causing errors.
Note
Another command that may be used to verify or troubleshoot, is lsmod. To use this command, first install the RPM file for lsmod, which is modutils. The lsmod command displays the loaded kernel modules of /proc/modules.
To see if third-party LKMs are affecting an error, enable safe mode. Refer to the "Safe Mode" section.
Safe Mode
Enabling safe mode on Cisco AXP prevents the system from installing third-party kernel modules at startup.
A kernel oops, introduced by a developer-provided kernel module, may send the system into a continuous crash loop. This makes the system inaccessible when the system installs all modules at bootup.
Enabling Safe Mode
To enable safe mode, perform the following step.
Step 1
###
The message "Entering Safe Mode" appears.
The following Safe Mode Menu appears:
1) Erase startup configuration
2) Show startup configuration
3) Show messages.log
4) Do not load third-party LKMs on startup
5) Continue
Enter 1-5>
Step 2
4
The following Safe Mode Menu appears again:
1) Erase startup configuration
2) Show startup configuration
3) Show messages.log
4) Do not load third-party kernel modules on startup
5) Continue
Enter 1-5>
Step 3
5
The third-party LKM is disabled.
Note
How to Build a Third Party LKM
This section contains the following procedures:
•
Building a Third Party LKM
Prerequisites
Check that the shell environment is set to use bash, before executing the make tools command. (If the environment is set to csh, errors might occur.)
Make sure that the linux distribution installed on your development machine has basic development packages installed, such as gcc, and gnu make. For example, in the CentOS 5.2 linux distribution, the following minimum RPMs are required to build the LKM:
•
•
•
•
•
The LKM SDK has been successfully tested on Debian, Fedora, and OpenSuse based systems.
To build a third-party LKM, refer to the following two sections:
Building the SDK
To build the SDK, perform the following steps:
Step 1
Step 2
A gcc binary in directory <path to sdk root>/image/gcc can be used to build a third-party LKM against the kernel supplied in the Cisco AXP SDK. The SDK kernel directory is:
<path to sdk root>/image/kernel-2.6.22/linux/include.
Note
For NME or AIM2 service modules PLATFORM does not need to be specified. The default is "PLATFORM=nme". For example, make tools PLATFORM=nme is equivalent to make tools.
Note
Note
glibc (2.7) supports the Native POSIX Thread Library (NPTL) and Thread Local Storage (TLS).
Building a Third Party LKM
To build an LKM against the SDK kernel, perform the following steps:
Step 1
Step 2
Step 3
Example
obj-m += hello1_22.o--include-dir=/<path to sdk root>/image/kernel-2.6.22/linux/includeall:make -C /<path to sdk root>/image/kernel-2.6.22/linux M=$(PWD) ARCH=i386 modulesThe second line has an --include-dir path that points to the SDK kernel directory:
/<path to sdk root>/image/kernel-2.6.22/linux/includeThe fourth line includes the path to the "linux" directory:
/<path to sdk root>/image/kernel-2.6.22/linuxStep 4
Troubleshooting the Build of a Third Party LKM
If the LKM build fails with the error indicating that "makeinfo" is missing, but "makeinfo" is installed and included in the PATH, check that the "makeinfo" version is between 4.4 and 4.9.
makeinfo versions 4.10 and higher may have issues due to a bug in the configure script logic that incorrectly checks the version of "makeinfo". There are two workarounds for this:1.
OR
2.
Step 1
# For an installed makeinfo, we require it to be from texinfo 4.4 or# higher, else we use the "missing" dummy.if ${MAKEINFO} --version \| egrep 'texinfo[^0-9]*([1-3][0-9]|4\.[4-9]|[5-9])' >/dev/null 2>&1; then:elseMAKEINFO="$MISSING makeinfo"fiChange the "egrep" line so that the above section of code looks like this:
# For an installed makeinfo, we require it to be from texinfo 4.4 or# higher, else we use the "missing" dummy.if ${MAKEINFO} --version \| egrep 'texinfo[^0-9]*([1-3][0-9]|4\.[0-9]|[0-9])' >/dev/null 2>&1; then:elseMAKEINFO="$MISSING makeinfo"Fi
Viewing LKM Support
To view LKM support details, use the show tech-support command in application service EXEC mode. show tech-support displays:
•
•
Building Additional Kernel Modules
This procedure is for building additional kernel modules from kernel module source files in the Cisco AXP SDK.
To build additional LKMs to support your system hardware, perform the following steps:
Prerequisite
Build the LKM SDK—refer to the "Building the SDK" section.
Step 1
Step 2
Copies the ".config" file to a backup file.
Step 3
Different kernel configuration options are displayed on the screen.
Step 4
For example, to enable driver PL2303 use the following instructions in the make menuconfig menu:
Select > Device Drivers > USB support > USB serial converter support > <M> USB serial converter support > <M> USB Prolific 2303 Single Port Serial Driver
Step 5
Step 6
Determine the differences (diffs) between the new, modified ".config" file and the old ".config" file (.config.bak). The diffs may include extra configurations required to build your module. Refer to diff: Example.
Step 7
Step 8
Step 9
The newly built kernel modules are contained in directory <path to sdk root>/image/kernel-2.6.22/linux.These modules can be viewed as follows:
:cd <path to sdk root>/image/kernel-2.6.22/linux: find -name "*.ko"./usb/serial/pl2303.ko./usb/serial/usbserial.ko:diff: Example
In the first part of this example, the diffs are checked and the following config parameters are obtained—CONFIG_USB_SERIAL=m and CONFIG_USB_SERIAL_PL2303=m:
:cd <path to sdk root>/gplCore/kernel-2.6.22/app_config/axp:diff dotconfig-regular-i386-nme.old dotconfig-regular-i386-nme26a27,31> CONFIG_USB_SERIAL=m> CONFIG_USB_SERIAL_PL2303=m>If the two parameters (CONFIG_USB_SERIAL=m and CONFIG_USB_SERIAL_PL2303=m:) are required to build your module, keep them in the ".config" file that is used when running the make modules command.
make modules: Example
:cd <path to sdk root>/gplCore/kernel-2.6.22: make modulessh <path to sdk root>/makeinc/build_native.sh \sh -c 'PATH=/bin:/usr/bin: <path to sdk root>//target/i586-os+fndn+app-devtest-nme/tool-chain/usr/bin \make ARCH=i386 \HOSTCC=gcc \CROSS_COMPILE= <path to sdk root> //target/i586-os+fndn+app-devtest-nme/tool-chain/cross/bin/i686-pc-linux-gnu- \-w -C<path to sdk root>//target/i586-os+fndn+app-devtest-nme/gplCore/kernel-2.6.22/linux modules'CHK include/linux/version.hCHK include/linux/utsrelease.hCALL scripts/checksyscalls.shBuilding modules, stage 2.MODPOST 15 modulesLD [M] drivers/usb/serial/pl2303.koLD [M] drivers/usb/serial/usbserial.ko:Cisco AXP Commands for Advanced Features
The following command is used for configuration of Advanced Features:
debug shell
To obtain unrestricted shell access, use the debug shell command in Cisco AXP EXEC mode.
debug shell
Syntax Description
This command has no arguments.
Defaults
No default behavior or values.
Command Default
None.
Command Modes
Cisco AXP EXEC.
Command History
Usage Guidelines
Use the debug shell command for unrestricted root shell access.
PREREQUISITES
Before invoking the debug shell command in Cisco AXP EXEC mode, install the debug shell add-on package after obtaining authorization from your Cisco representative.
Refer to the "Obtaining Unrestricted Shell Access" section about installing the debug shell package.
Related Commands
show software versions
Displays the software versions.
show tech-support
Displays diagnostic information about the application environment.
References
Reference other Cisco AXP guides under "Support" information at: http://www.cisco.com/en/US/products/ps9701/index.html.
Notices
This product includes software developed by the OpenSSL project for use in the OpenSSL Toolkit.
For further details, see the "Notices" section of the relevant Release Notes for Cisco Application eXtension Platform.Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
