Network Management

Was about to update AirWave and noticed a nice little warning message that the CLI would no longer be available.

 

At least it was in the Relase Notes, unlike the whole adding docker to AirWave.

 

Looking at 8.2.4 User Guide Appendix B it looks like the replacement to the CentOS shell is a choose your ending number menu.

 

Way to suck...

At least give me a number option to drop back out to a real shell.

 

 

Thanks for the feedback.

 

There was much debate that went into this feature, and this is just the initial roll out.  As we continue forward, we're hoping to develop custom modules to restore some of the functionality lost by not having direct access to the shell.  If you could help us distinguish which CLI operations you commonly perform from the CLI, we can start to plan out improvements.

 

We already have a request for a subset of network debugging tools: ping, traceroute, tcpdump, nslookup.  And we're keeping a watchful eye on all inbound requests.  So expanding on your feedback response would help a lot in shaping the future of the product.

A way to escape to the full shell would be much appreciated.

Menchini, again, what needs do you have critical to the operation of the AMP do you need root access for? 

One thing I use bash for is to automatically move the daily backup files
off machine into our archival and DR systems using bash scripts I've
developed and deployed across my Linux servers.

Menchini, automatic daily SCP of nightly backups are there now, RFE for adding Windows shares. So if you are archiving your backups to linux now or an SCP server, you can do that today and have the script change the name once it lands on the target server. 

I'd suggest to log into innovate.arubanetworks.com and file the suggestion.

 

You might reference NMS-I-810 , which is a request to make this security

feature optional.

 

I'd like to add a request for a full shell menu option.  

Do I need to add that to the idea's feature request? 

There will not likely be any addition to the AMPCLI to enable full root access, it defies the purpose of putting this in in the first place. 

 

A list of what you need root access for that is critical to the operation of the AMP server would help us understand your needs and requirements, or address them via the other alternative paths provided in the GUI or AMP CLI, and if they aren't there, we can add them. But root access, just to have it, is not likely going to be a valid reason. 

One other use for the CLI.

I didn't see how you are able to load a Web https certificate for AirWave now. 

 

Was there a feature in 8.2.4 that allows us to change the web cert in the GUI? 

Web certs are now required to be pkcs12.  once uploaded, you can apply the cert using the Add SSL Cert option under the Security submenu.

 

Under the Backup submenu, there's adding a destination server.  This will automatically scp the nightly backup to the destination.  Only nightly backups, not the forced on-demand backup.

Will you be adding a CIFS option and not just a SCP option for the backups? Many are only using Windows fileshares and do not have a SCP destination. 

 

CIFS option would be a feature request.  If you had a script/cronjob running in the background that was performing this task, it should still be active post upgrade to 8.2.4.  Disabling of previously configured cronjobs and custom scripts will be taken care of in support cases.

We manage our own Airwave server (not an Aruba appliance) and need CLI access to monitor system health and to perform other management functions which are not available via the GUI, such as
1. Monitor individual SSD health using SMART statistics and RAID statistics and send weekly email reports of SSD status.
2. Local IP tables to allow access and disallow unwanted access.
3. Copy nightly backups to remote storage.
4. Periodic purge and rebuild of the database.
5. Weekly restart of AMP services (to prevent swap space from filling up, etc.)
6. Various other ad-hoc monitoring of the server to verify system status and troubleshoot issues like access to APs, controllers, SNMP issues, syslog issues, etc.

Several of these (e.g. SSD health and copy of nightly backups) are done via CRON, not manually. We don't specifically need root access, but some of these (iptables) require at least sudo.

 

 

 

1. Can look at filing an RFE to add advanced disk diagnostics to the 'Performance' page.

2. I thoguht we had an allowed networks list, but apparently not. That should be an easy RFE to file on the 'Networks' page to get parity with CPPM

3. This is already added in AMPCLI

4. This should not be necessary

5. Also should not be necessary.

6. More troubleshooting support will be added to AMPCLI over time

Hi Jerrod, I'd like to throw in another vote for scripting or cron management in some form or another, as we cannot upgrade without access to modify the custom scripts managing our ArubaOS controller via "on_controller" commands.

 

Support had some suggestions on how replace the scripts with some configuration changes on the controller, but I fear those adjustments will simply confuse my users.  The only real solution seemed to be configuring a device simply to remote into my controller for scripting.  I'd prefer to limit how many systems I need to manage my Aruba infrastructure (seems to be 5 separate UIs I need to access across 3 devices).

I'd prefer to have a full shell available for when I need it. And so far we've needed it. We couldn't have deployed AMP 8.2.3.1 without a root shell, because of the need to resize the underlying volumes and filesystem. 

 

I wish I had know that this was the direction Aruba was headed with their products, before we bought them. 

Re-scaling the disk is usually handled via creating of a new AMP deployment with the proper disk settings and then restoring a nightly backup on to the new platform. While some can properly re-partition and format, most fail and leades to big support efforts and usually loss of data. 

Jerrod, 

 

I don't follow. What is deploying with proper disk settings? How would I deploy the OVA a second time and get different results? 

 

Generally, you would use the OVA for demo, and then for a production installation you would install from the ISO and manually configure a CentOS AMP VM with the required settings and resources outlined in the sizing guide. 

To add, the AW installation guide highlights (Table 1) that the OVA is optimized for up to 100 devices. Otheriwse to use the ISO.

 

I wish we would post up multiple OVAs pre-configured, that may happen at some point later on. 

---

@jhoward wrote:

Re-scaling the disk is usually handled via creating of a new AMP deployment with the proper disk settings and then restoring a nightly backup on to the new platform. While some can properly re-partition and format, most fail and leades to big support efforts and usually loss of data. 

---

I have resized Airwave disks numerous times via the CLI without any issues whatsoever. Isn't it just a matter of not messing up any of the commands?

These work magic by the way (well right up until 8.2.4 that is):

 

lvm pvcreate /dev/sda#
lvm vgextend "VolGroup00" /dev/sda#
lvm lvresize -l +100%FREE /dev/VolGroup00/LogVol00
resize2fs /dev/VolGroup00/LogVol00

 

Let me see if I can help address some of these comments.  I'm also fwding to PLM so that they can review:

 

@jeff.g.kier - snmpwalks = US16804

 

@alow - change graphics - need more info, which images are you changing?  I've filed US16805, but need more info on the specifics that you're changing for PLM to make an educated decision.

 

@HLavender -

cert generation = US16631 (w/ CSR), US14594 (just cert generation, no CSR)

there's no SCPing of files between 2 AMPs.  If you have Failover, it will still get the backups of the monitored AMPs via http/https.

 

@Michael_Clarke - static route = US16801

 

@gilmorrr -

backups -> see the backup menu, there's a 'set destination' that will auto SCP backups to a destination.  If you already had a script performing this in a cronjob, that cronjob will continue to run.  Edits to cronjob will be mitigated in support cases.

db access -> if you can expand on the tables you utilize the most, then we can make sure the APIs get expanded to cover those tables

mass import = US16806

 

@Chris F

ifconfig / bonded interfaces = US16625

 

@Sascha Becht

db access -> if you can expand on the tables you utilize the most, then we can make sure the APIs get expanded to cover those tables

Rob

 

We often change the following on some of our AMP servers.

 

/var/www/html/images/theme/airwave/title.png

/var/www/noauth/theme/dev/login-logo.png

/var/www/noauth/theme/airwave/login-logo.png

 

We use have been using these appliances in a manged services enviroment for a number of years and have given cusotmers access to the AMP appliances to run reports etc. So we have changed some of the images to reflect the platforms function.

 

Its a small change but they need to be updated every time we patch the appliances or deploy a new one.

 

thanks

Andy

Got it, added the details into the feature request.  PLM are planning to review the items filed this week.

I miss being able to see which process are up - especially after a reboot.

As a power user of nearly every system I encounter, I like the ability to get to a shell - I want one in CPPM as well.

The thousand or so times I've needed to have or give shell access to Airwave for TAC, never mind system admin tasks make it seem logical to provide a shell.

You've asked us to justify why we should have it back, but I haven't seen an explanation of why you took it away.

Can you shed some light on it for me?

---

@msabin wrote:

 

You've asked us to justify why we should have it back, but I haven't seen an explanation of why you took it away.

Can you shed some light on it for me?

---

PLM should probably be the ones to respond to this.  Fwded to the PLM team.

Hi Matthew,

 

We removed the root access because our most security-concious customers view this capability as a security vulnerability.  And they're right about this point -- a user (or bot) with root privs can do essentially anything on a server, including malicious activities. 

 

We also recognize that our customers have been able to do a lot of great things with the privileges.

 

In prepping for 8.2.4 I talked with customers, with support and with our account teams to prioritize the most important things that users do at the CLI.  I know that we didn't implement everything.  

 

My plan is to continue adding to the CLI feature set to help you accomplish more of these things.  In reading through this thread and getting feedback through other channels I know that customers want to a bunch of things including: 

 

- Increase disk size

- View/control processes

- Transfer files

- Update files

- Test device connectivity

 

We are looking into doing all of these in 8.2.5.  In the meantime, anybody who wants this or other can request (via the CLI menu + TAC) that we add a custom menu item.  

 

Thanks,

Dan Comfort

Product Manager, AirWave

 

Thanks Dan

I would have liked to be one of the customers you talked to ahead of time, and I would have liked to know before hand what was happening.

I completely agree that root access was a bad thing.

I however think that no visibility under the hood makes the appliance less secure - I'm now completely having to trust Aruba to secure the OS and can't easily check when my PCI assessor asks if we're patched.

I'll learn to live with it as I need the tool more than I need to have full control.

Clearly this is not to address customer security concerns, as we suggested to PLM serveral times that if a customer requires this there is simily an option to turn it on (similar to how FIPS is implemention on ClearPass or on the Controller).  We have serveral customers who use custom routines on the linux shell of the server.  Aruba/HPE clearly wants to shut down this access.  Security is not the answer...

Hi @ all,

 

i am new at Airwave. i will miss the cli, too. We use Redhat here, so my first idea was to install Airwave to one of our RHEL Systems. So i could use our standard backup tool HP Data Protector. 

i think, it should be my decision which Linux, i will use for Airwave. With Airwave on our RHEL i would have a perfect integrated Airwave System. 

 

Greetings 

Christian

 

PS: Sorry, no english speaker

Changing sides of the fence - I completely agree that remote root access is a terrible security risk. I prefer the model where a general user login with sudo permissions can greatly improve security of the system.

I forgot one point: Icinga!

I do have to agree with @fredw his post here though. This could have been made optional as an added security feature. Or another solution would have been to implement two factor authentication. 

 

The Airwave upgrade procedure already requires your Aruba credentials to download images, something similar could have been implemented for root access. 

 

It kinda makes me wondor if this was done to prevent customers from screwing things up via the CLI. You can easily mess up your entire Airwave installation with 1 wrong command after all.

 

That being said, if Aruba manages to add the options listed here in 8.2.5, the closed shell should become a lot more practical already. 

We would appriciate it if you had the 'additional functionality' in place prior to removing the regular functionality.  Many of us use OUR ( not your ) servers for other purposes and you have just removed our ability to levergage OUR hardware the way we see fit.   I do not know any of your customers who are happy with this change.  It has cerntainly pushed us to look for other solutions.

Hi,

 

Any news about include vmware tools support ? because it is complicated to ask to TAC for each upgrade of AirWave (when there is a Kernel Update !)

In the VMware tools note, also request LIS for Hyper-V.

So, today I opened yet another TAC case for 5 new issues that we are facing in light of this horrible decision.

 

Let me know what Arubas though on these are:

 

1. We need to add more routes to the Airwave server. We are not able to do that when the root access was removed. 

2. We are unable to add additional network interfaces to the machine. Was easy to do before, now it is a problem.

3. How do we install the certificate and generate a Certificate signing request? This is for the web interface.

4. When the upgrade was made to 8.2.4.1, backups stopped running. They stopped completely. We previously used a bash script putting the files on an ftp server after backup was done.

 

5. Still, SCP file uploading/downloading does not work. Yes, TAC has looked into this has has no solution. Tried linux server, TAC recommended ones etc. Nothing works. Works with other clients/services. Not Ariwave

mholden, while we appreciate the deep, insightful feedback of "Way to suck", it would be far more helpful to inform us on how you are using the CLI and why you require access to the root shell.

 

Access to the shell has causedd no end of support issues long-term where changes were made, packages installed that resulted in stability issues, modifications to settings made that created long, difficult to pin down root-causes that were impacting customer perception of the product. Additionally, leaving root access was a threat vector of bad actors having access to the system adding in software that exposed the machine to additional risk (packages that added CSS vulnerabilities and exploits via some web interface installed as part of the 3rd party package).

 

No other product in the Aruba portfolio leave access to the shell open and this is just the evolution of AirWave into a more secure and stable product. While we can appreicate a small handful of customers that like having access to the shell, it's not a requirement and so long as our customers are informing us as to what they need from the shell that they aren't getting from the AMP CLI and GUI, we can add those support features in as needed. 

 

Thanks, as always. 

Jerrod sorry, you are correct, knee jerk reaction. 

 

While full root access is not strickly needed, shell access has been VERY useful.

I've always hated loggin in a root, a user accuont is much better, and I've in some cases created such an account. 

Shell access is VERY much appreciated and used. 

I've used it as everything from a make shift SCP server so that we can get flash backups off the controllers, to a jump box for being able to change the default route on controllers. 

 

Root access has also been required when creating mount and backup scripts in order to have AirWave backups go to CIFS shares. sudoers would be fine for these functions. 

 

Another reason for shell Troubleshooting and Upgrading. 

 

Perhaps a balanced approach of going therough a couple of menu options to get to a user shell, and doing the one time key to get full root access like on the controllers would allow for flexablity while reducing the support calls.

Some of those have been discussed to be added in future versions (adding a module to enable offline backups or to make the scripting of backups easier). Downloading of the logs should contain all the troubleshooting logs moving forward (and if not, TAC case will file a bug to add that in). A jump box, while handy (and I've used it many times), it's not a feature we support or advocate so losing it shouldn't be a critical loss. 

 

SCP server host still works with the AMP CLI, you can load up and down files into the AMP via the AMP CLI to use for controller firmware, move files in and out, load certs and new packages, etc. 

 

However, there will not likely be any steps or processes that ends up with the ability to get any root access to the system, via user account, sudo, or otherwise. Thanks for the feedback, we will bring this up with PLM and engineering as things to add in. 

A few of the things I have used CLI access for:

 

1. Changing timezone (there was no GUI option for this in previous versions, don't know about 8.2.4).

 

2. SSH from Airwave server to Aruba controllers and switches has been valuable in situations where TAC needed quick access.

 

3. Keeping VMware Tools updated (our server guys are always bugging me about this).

 

Jerrod,

 

For me, the real issue here is the order that aruba used to make the change.  Instead of pulling the feature that people used and then asking what was needed, it would have been better to reverse the order.  Find out what tools people needed and then have them available when the feature was removed (or at least have a timeline for the features getting added). This product has been this way for a long time and there should have been a way to get this information before making this change.  

 

JUst my opinion.

 

Michael

I agree with Michael_Bloom. A change like this should be communicated to all customers well in advance, at least 6 months. You should use that period to collect feedback about what shell features are needed and used.

I also periodically use the database CLI to make queries - is there a way to access the database from an external reporting tool?

Hi mholden,

 

after the amp is upgraded do not log of. Before you close the cli make the following change.

 

change the file : /etc/passwd

 

change the first line to: root:x:0:0:root:/root:/bin/bash

safe the file and you can still login to the airwave with your root user

 

 

Note that if you choose to perform such actions like editing core permissions above, that you create a potential security hole, so run this at your own risk.  Also, if security compliance is a requirement, most current scans fail when root permission accounts are available, so keep that in mind if security is a priority in your network.  And it's likely something you'd have to remember to perform at each upgrade.

Hi Rob,

 

you're rigth please do this at your own risk.

please also keep in mind that there are no permission changes. Only the root default login directory is changed.

 

If there is a known root security issue please report this to the centOS development team (www.centos.org)

 

I know why aruba is acting like this. It is a big security risk if a admin have access and they don't know what they do.

It might also be usefull to have an option to install/upgrade vmware tools for ESX based installs.

 

 

Also not a big fan of this new menu based CLI. Question, do I now need to make a TAC case to perform the following?

 

- Expand the disk size > this is quite a common problem/request with our end customers

- Check running processes or disk space (top & df -h) > makes it easier to spot issues or a full disk

- Change the timezone

This is all useful feedback.  The Product team did communicate with several customers when building up the plan for the feature.  And the feature has been shown at Atmosphere, Aspire, and Discover events.  While there could have been more of an announcement of the feature, the upgrade notice does allow you to bailout if you do not want to run AMPCLI.  The custom modules structure in the menu is designed in a way that we are going to be able to address some of the requests sooner than the next release.  This was a 1.0 feature release, so there's room for improvement.

 

That said, let's move forward by making requests for enhancements and modules that address options that are now missing.  I've been adding them as feature stories, but it doesn't guarantee that it will make it into the scheduling - but like all features, the more requests for a feature - the more likely it'll be implemented.

 

For tracking:

US16673 : option to update timezone

US16776 : vmware tools installation

US16788 : expand disk size

US16789 : CIFS option for backup transfer to windows fileshare

 

Workarounds:

For processes, you can request through support for the 'process list' module -> while it's not top, it does show the running processes.

For disk space -> you can use the Disk Usage alert (it has an email option as well)

 

No longer a usage case from AirWave server:

 - Full shell access

 - Allowing CLI user to SSH into another server or networked resource via AirWave server

:: REASON ::

The above 2 items are being caught by security audits as security vulnerabilities.

 

For things that don't have a workaround, a support case would need to be opened to address the changes needed and help track the module &/or feature requests as they come in.

it would be also helpfull to get a DB access with select commands.

To troubleshoot some airwave bugs.

 

 

+1 for DB access

 

I have often used direct access to the postgres database on large sites to do detailed analysis & reporting. 

 

 

Also changing timezone. 

 

The 8.0.11 -> 8.2.4 upgrade reset the timezone to PDT.

 

No way to change it.

 

 

Timezone option will be included in the next release.  It will appear under the Advanced sub-menu:

 

Advanced
1 Restart Application
2 Reboot System
3 Configure Network Settings
4 Set Hostname
5 Set Timezone
6 Shutdown System (halt)
b >> Back

I would like to add to db access. I run a couple of simple and custom automated (crontab) db query reports reports every day. I would like to be able to continue running these, add others if necessary, and modify the custom reports I have created please. I also use the "mail" command to send them off.

 

Example:

[root@hostname mercury]# more /var/airwave/custom/AMPReport_APs_PlannedDown-Down
/opt/airwave/pgsql/bin/psql -Uairwave airwave -c 'select name from ap where is_up = 0;' >/root/apsdown.txt
/opt/airwave/pgsql/bin/psql -Uairwave airwave -c 'select name from ap where planned_maintenance_mode=1;' >/root/apsplanneddown.txt
/bin/sort /root/apsdown.txt >/root/apsdownSorted.txt
/bin/sort /root/apsplanneddown.txt >/root/apsplanneddownSorted.txt
/usr/bin/join /root/apsdownSorted.txt /root/apsplanneddownSorted.txt >/root/apsplanneddownNdown-amp.txt
sed -i '/^$\|name\|(\|-ACT\|YBR\|IDF\|Lab\|LAB\|-idf/d' /root/apsplanneddownNdown-amp.txt
sed 's/\r//' /root/apsplanneddownNdown-amp.txt
mail -r amphost@corpdomain.com -s "AMP APs Planned Down and APs Down Report - Daily" myname@corpdomain.com,mycoworker@corpdomain.com < /root/apsplanneddownNdown-amp.txt

 

Thanks

 

Absolutely. I used direct DB queries quite frequently, was one of the great things about Airwave, but no more. It's just another locked down NMS now.

A new cli "command" I learnt about today was delete_rogues_by_age.pl

 

It is a usefull command as one of our AMP servers detects a huge number of rogue so maybe it would be worth adding that set of commands/scripts we can run via the ampcli.

Indeed.

 

Airwave is still unable to handle a large influx of logs well. Certain network issues can and do choke up the database and lead to basically all airwaves functions slowing down or griding to a halt.

 

If these are triggering alerts you end up with millions.

 

With DB access I could simply run a query and delete them.

 

Now I have to auto ack alerts to 1 day, then clear acked alerts after 1 day. Then in 48 hours I get airwave back, assuming the problem has stopped occuring.

 

The fact a key appliance for troubleshooting network issues is so easily DOS'd is one issue. But the fact we have been handicapped from fixing the issue is a bigger one.

 

The problem is that I can’t bail or opt out because we are deploying AP-303H’s and AP-365’s and we need to be able to monitor them. I now have to figure out what to do with the agents running on centos for our backup and monitoring systems. I'm guessing that the only solution in not to use these systems.

 

Also, I occasionally need to run ifconfig commands and would like to know if there will be a way up/down and bond ethernet interfaces from the new CLI.

 

Thanks,
Chris

The elimination of the CLI for us has put a halt on further upgrades to airwave, and we well be evaluating the next step going forward. My first thought was they are turning the Server/application into an appliance only device when I saw this going on. I have a lot of questions that I am trying to research answers to if we don't have CLI access.

• Backups

Right now, how do I do the following without access to the CLI?

We currently mount volume to our SAN for backups. This solved the problem of constantly running out of space on the drives and gave us an off the server backup in the event of a crash. Which we were bit by a few years ago when drives failed.

Here are the mount points. that we ship over to the SAN

/var/airwave-backup type ext4 (rw,_netdev)

 /alternative type ext4 (rw,_netdev)

 /airwave-logs type ext4 (rw,_netdev)

 

• Database

Database Access provides us with three main usefull data/tools! 

1) Data that we transfer over to long term for our CIO's project. This gets integrated with other systems. If we can't access it via the cli can we access it via ODBC to provide this data? Then how do we set this up if we do not have access to the CLI or root access? It is our data we want and need access to it. How are you going to do this for everyone who needs to access the database without the CLI?

 

2) Mass Imports for Location and AP updates. When we get a few new buildings that are rehabbed the AP's are updated and then I have a few hundred AP's to rename, upload Location information, and AP group information for. Now to do this via the GUI it’s slow and takes a very long time. I can do this via the database access in about 5 minutes I would be really pissed they had not figured that out first before removing access. ( This is coming from a long time customer!) Because now you’re talking days of work instead of minutes. 

 

3) Database access for trouble shooting. We use this all the time to identify AP’s, as it's a lot faster than the web GUI. So work needs to be done to fix the slow interaction between the Database and the Web GUI. It just plain slow to access the database and update! 

 

• OS Lockdown

I get that you want to have your app "airwave" run on a certain version of CENT OS so it's certified to work with it. That is the easy way out if the world didn't evolve. But the base OS must be kept up to date and therefore the application must be as well. We have far too many applications that simply refuse to keep with the times simply because they don't want put the effort in to testing or money on a new OS.

 

Somehow, this needs to be reversed so that all systems are secured by not limiting the OS version to that which the application can support. We pay enough for support and the product upfront so it should be kept up to date! Therefore, this last one I do see a valid reason but still not enough of one to kill the CLI entirely and replace it with Menu driven system. 

 

That's my thoughts on the subject. Simply put a Menu just will not cut it; you have just handcuffed the product. We all don't need to be root. Say wny not create a user class say call ampuser and amp_operater so that there are levels of access... isn't that a unique idea to computing and security? 

adding a static route.

I was looking forward to this release (8.2.4). The Security team ran several scans against 8.2.3.1 and were not happy with the results. I spent countless hours patching and applying STIG settings. Prior to this, I had to run the "convert_to_sercure_amp" script. It had limited functionality and was very slow.

 

Feature request:

- Being able to use Open SSL to generate certificates

 

Thanks

Question: Can AirWave servers running 8.2.4 copy files between each other. Let's say a Primary AMP and a Failover AMP...can files be SCP'd between the two devices using the AMPCLI? Or do I need to introduce an additional SCP server?

 

On 8.2.3.1 (prior to converting it to a secure AMP), I would have shell access and would SCP the backup files directly between each server...when there was a failover event. I assume this functionality is there now using the numbered options? Or, has the SCP server functionality been removed?

 

Thanks

We often change the graphics on the login page so that is another reason we would need ssh access.

The best solution for all is to generate a SSH access with OpenPGP like the new AWSupport Access.

 

With OpenPGP there are no security reasons to terminate the CLI

Another feature request/CLI function is MIB Walk to confirm SNMP is working or if interfaces or values can be accessed from controller IP.

MIB Walks are getting added to the AMPCLI in a future version.

We spent a considerable amount of time troubleshooting SNMP after installing 8.4.2.1

 

When it is first started the CLI root access is available. We did some successful 'sw' commands from the controller. But no amount of copying and pasting into the web interface would allow the SNMP functions to work. We saw an old post that suggested rebooting the system and it would "fix" issues from first starting an .ova file. So we attempted it, and it was still broke.

However, after reboot we were unable to do the 'sw' command because we did not have root access anymore.

 

In a way the reboot did "fix" the problem, because it allowed the Web interface to finally "accept" the data we were pasting into it.

 

Now I just need to get remote backups working. scp is usually easier than this, because you get to see the output of the command or use -v for verbose.

 

BTW, your CLI Menu sucks. It should not have made it out of beta. Call up some HPE/Aruba Procurve CLI Menu designers and get a few pointers.

ot that problem as well. After 8.2.4.x is installed but the server is not rebooted. Some things work, some does not.

Really annoying.

Just to make a suggestion:

 

Here at work we have devices where root user is disabled by default, however, those devices have a command sequence that allows root access to be enabled temporarily specifically for advanced troubleshooting.  Once the session is over, root user is again disabled.

Menu option > Advanced Troubleshooting > CLI prompt to enter command to enable troubleshooting (e.g. root-login enable) > Non-root user prompt > su commands.

 

It's not perfect, but it has saved a lot of headaches being able to ping, traceroute, snmp walk, etc. among other things.

At what version level is it expected that a reasonable level of functionality will be returned?   It's clear that I should downgrade to 8.3.x until such time as the product is usable again.

We cannot have TAC make changes.  Remote access is simply not allowed and never will be, so basics such as networking, network troubleshooting, routing, backup/restore to/from cifs shares, vmware mgmt tools, upgrading (we do not have mac/linux and your current solution does not work even with bitvise, and doesn't work from HPE), time settings, etal, MUST BE WORKING PROPERLY before we can move to your product.   

 

You should never have removed the CLI without ensuring that working functionality was in place, or you should immediately provide a sudo alternative as suggested by many other posters. 

I'm in a situation where TAC wants to upgrade AMP to resolve an issue. It is a tradeoff between a potential fix and losing CLI access or staying at this version and continue to deal with the issue. AMP will stay where it is for now.

You can re-add root access by following the steps given before. While not
suggested it can work for you.

--

Eric Pribish

NOC DIRM SE (OC-382) | System Engineer

Work: (303) 236-0571 | epribish@blm.gov


Building 53, Denver Federal Center, PO Box 25047, Denver, CO 80225

DOI/BLM Contractor | Team ASRC Federal Vistronix | *Customer-Focused.
Operationally Excellent.*

I'd like to add my vote to completely dispose of this new menu system and restore a normal UNIX CLI.

 

You are making work for all of us to work around this trash and we are very busy as it is.  We'll be bypass it by any means necessary at the point where we are forced to go up to 8.2.4 and will avoid going up to 8.2.4 for as long as possible.

 

If we have to immediately respond to a security issue, and cannot because of the CLI, telling us to enter a long, drawn out TAC process is not an acceptable solution.

 

You will never cover all the use cases for a CLI with your prefab menu system, simply because CLI on UNIX systems is there to help you deal with the unexpected and the unforseen.  You are just making a huge mess.

 

 

 

 

 

We have just (right now) upgraded to 8.2.4 and the upgrade changed the system timezone, without asking.  I now have no command line access to set the timezone back.  All the inbuilt system logs now show the time as EDT, which does not help us as we are half way around the world from EDT!!

 

If you are exactly half way the other side of the world, just swap the AM/PM ;-)

 

No, seriously, you should contact Aruba TAC and they can make the change in time-zone for you (I had my timezone changed too)

 

Changing the time-zone is mentioned on page 3 of this post:

US16673 : option to update timezone.

Hi Ross,

 

Please open TAC ticket to set back to proper timezone. We dont have option to set the timezone from GUI.

 

Regards,

Pavan

You can always just re-install the server.  There is an option for setting the timezone when you install the server.

Fred,

 

There is no need to re-install the server to just change the timezone, when we have option to set timezone and date from CLI (just that need to take TAC support now in 8.2.4, since root CLI is deprecated ).

 

Regards,

Pavan

Security is good risk for removing the shell, but the issue i see around everywhere is companies asking the CISO or people in management and not the technically people who can actually work the issue out to make it less of a concern. Stop asking the management and taking their feedback as concerns when they 1. don't have the technical skills to understand the concern and 2. don't involve the technical people with the skills

Multiple things I miss:

Able to view all error logs of the system

Able to grep the traps and syslogging information (lets all admit it sucks on the page when you are looking for one log)

Able to customize the look/branding of the system

Able to complete certian task without having to call TAC

Also, being where I work and giving a Remote Support person the ablity to access and internal system and not over-watching their action is a bigger security risk than leaving the shell. BTW this is Government Work I do.

Opened a TAC call - all fixed.  Great service (as usual), but the number of hoops the poor technician had to go through - felt really sorry for him.

I will miss the CLI access, we were using the Airwave server to back up our controllers using scripts from the knowledgebase, and we had to get in there every so often to tweak things - now every time we need to log in it will be a TAC call.  Maybe if enough people log enough TAC calls for CLI access for small tasks, we will get it back?

 

We utilized the CLI for backups.  Our linux team basically replaced the /var directory with a mount point to their storage which is backed up nightly.  This eliminated the need for us to write our own clean up script as Airwave already has one.  Will this still work after an upgrade to 8.2.4?

 

Thomas

Thomas,

Changing mount points will no longer work in Airwave 8.2.4. It might be that your current mount point will remain during the upgrade, however as you will not have access after the upgrade it is recommended to revert all such changes before upgrading.

Airwave can automatically copy out the nightly backups via secure copy (scp); so that will be the recommended way for backups.

Unfortunately that puts me back at square one as we will then need to code a script on the external location to clean up the old backups to keep them under 4 at a time.  Is it possible to request a module that will allow us to use mount points?  Otherwise I may be sitting on this version for a long time.

If you want to request a feature or module, please go through your Aruba partner or local Aruba SE to see what is needed to enter that process.

My only concern is now we can not use WinSCP to copy/edit files to fit our enhanced security position.  I should be good for now, until the next audit says we have to remove another TLS cipher.  A two factor access method to root would be a good start.  A module to enable/disable TLS/SSH ciphers also.

WinSCP should be getting fixed in an upcoming release (WinSCP doesn't allow the modification of ciphers). You can use BitVise (which DOES allow customization of ciphers and enablement of the more secure ciphers) *AND* BitVise has exceptional logging that wil clearly tell you why it failed and what ciphers to use. 

 

It's a good RFE to list/allow for enableing/disabling of other ciphers. 

Good to know.  WinSCP was a quick and dirty way of editing pound.cfg directly to adjust ciphers, but also helpful in other ways.

Following up on the cipher list/change.  There should also be a method of specifying the Diffie-Hellman key length.  This was previously done by using openssl to generate a new dhparams.pem file.

mforrest, that's a good tip, one we hope to add in a future version. For now, most of the secure ciphers are allowed. I don't know if they will make it available to add the unsecure ciphers, most of what will be allowed will be what are NIST approved (that everyone should be using as the base-line available certs anyway heh). 

This is a big step back.

Alot of what was easy to test/diagnose/fix is not gone.

 

Like many Aruba products these days, it´s also plagued by bugs. Even the reset admin password does not work. And updating Airwave? How the hell ? Nothing works. The Upload file does not work. Downloading from Aruba takes forever (literally 15% in 1H).

 

This is the worst decision by far.

It is really annoying. You should bring the CLI back.

 

Focus on things like quality control and improve on things that people ACCUALLY wants.

 

 

Download speeds from support should not be a problem, 15% @ 1hr is too slow. Unless you are far away from one of our ADNs, it should be much faster (though the upgrades are nearly 2GB, so it could take some time on a slow connection). Bugs should be getting TAC cases opened if they are affecting you. 

 

The root access will not be coming back. Many of the needs asked for in this thread will be coming in later, but not unfettered shell. Thanks

Well, the root access not comming back is really idiotic.

Since Aruba did not properly adress the concerns before and now "saying" that some things will be added. You have a really bad track record of that.

 

Downloading via the cli from aruba support has always been horrible. Many customers attest to that.

The normal support portal give normal speeds. And NO it is not my connections that is the problem. For once, own it and accually look into your own problems.

 

I am now locked out of the Web GUI. Thanks Aruba. Good testing..

So basically what Aruba is saying the one feature everyone is asking for back will not come back (cli/shell). So this tells me I should look into dropping Airwave completely from my environment and move to something else such as Solarwinds? or another product... But along with that might be ripping all Aruba out of the network... With this lack of meeting different customers needs customers will leave.

Does our bash scripts still work for moving backups off server?

Or is that now also broke? Well, we can never modify it again.

 

What is the solution here?

If the root CLI will not come back: I think there could be another way. 

Two Versions of Airwave, one Version is the appliance whithout root and full service. The other Version is a tar.gz, which can be installed in a distribution of my own choice....

To SK and Mikael, the AMPCLI support custom commands, where you can work with TAC to create a loadable module that does something specific. While you wouldn't have unfettered root access, if you have a script that pulls something regularly, then TAC may be able to build a module that supports that function from the AMPCLI. Up to you though if you want to pursue that avenue or not.

Speed through the CLI upgrade should have a TAC case opened. If you're able to download from support faster than AMP is able to download from the CLI, from the same network, that needs to be looked at.

 

There is a mechanism now to automate moving nightly backups off the AMP from the AMPCLI. 

 

   4. Backup > 2. Configure Automatic Transfer 

 

While there are some customers that would like to retain access to the CLI and root, there are many, many more from both large enterprise and high security spaces (state and federal governments) that do not allow root access to the box, and leaving that access in, in any fashion, removes their ability to deploy. Additionally, future versions of airwave will have to absolutely remove access to shell to meet other high security certification requirements as a pre-requisite to even be looked at before deploying on a government network. This limitation (lack of access to root privledge) also applies to all of our other competitors in this space as well, so it's an industry direction and best practice for most all network appliances.

 

No other product in Aruba's portfolio allows access to root, AirWave was the anomaly and it's now being corrected for both reasons stated above. 

 

We of course regret that this negatively impacts some of our customers that use root on a regular basis, and we certainly hope they wouldn't leave, but this is a much larger product design requirement than just removing it for the sake of removing it to make our customers angry. We have asked for, and received, many enhancement requests on things they were using root access for and we will be adding them in upcoming releases. If you see missing features that you used the CLI for in previous posts on this thread, or have one that you use that are critical for your operations, feel free to post it here.

 

Thanks

If you did not change the /etc/passwd file after the upgrade as  Sascha Becht suggested earlier you should be able to use sinlge user mode to get logged in.

You can follow the root password reset process from here.

 

To get it all in one spot.

 

1. Reboot the server with CTRL-ALT-DELETE.
2. When the blue boot screen pops up (depending on what OS you have, you may have an AirWave logo or CentOS or another OS logo on this page), press "e" to edit the boot configuration.
3. Move the cursor down to the line that starts with 'kernel', and press "e"
again to edit that line
4. Make sure you're at the end of the line, give a space and add the word "single" (without quotes) to the string, then hit 
5. Type 'b' to continue the boot process; you'll boot quickly into a shell without having to enter a password
6. Use the 'passwd' command to enter and confirm a new password for the root user
7. Write down the new password and keep it someplace safe.

8. Add root acces back vi /etc/passwd

9. change the first line to: root:x:0:0:root:/root:/bin/bash
10. Use the 'reboot' command to reboot the server into full operations mode.

11. Log back in and create new user so you can log in without root 

 

Jerrod,

 

I find your reply/comment BS. In high security government environments there is no way they would allow you to build a vpn tunnel back to TAC and allow them to work on the server without an overview watch. 

 

 

Secondly, 

To say TAC would have to build modules is another way to say "hey customer you need to pay us to build your module."

 

So come on lets cut the bs on that.

 

Now I will say yes other vendors don't allow access to the backend code, but Aruba basically ripped it out for no reason.

APKeene, you don't have to build secure tunnels to have a module created, you just need to exchage the GPG key so that we can sign modules that will work on your AMP. And while there is a 2-factor GPGkey tunnel established that, in some cases can meet the GOV requirement, if the customer's network disallows that, we can still support via the regular way (pull log files, diagnose over phone, with webex, etc. 

 

If you have a valid support contract, that service is included and is not any extra charge. 

 

The reasons are stated above, I cannot be any clearer. 

 

 

Sadly it does not work if you use the centOS image Aruba provides. Anyone have an easy way to get past the GRUB password to get into single mode?

Get around/reset the GRUB password: 

 

Yes, you need to boot from a Live Distro, or mount the disk with another VM. Knppoix/Ubuntu/Backtrack are what I typically have on hand. If you use Ubunut make sure you use "Try without Installing" / Try Ubuntu and don't install over your AMP server

 

- Shutdown the AirWave VM

- Add CD ROM to VM, and mount ISO to CD ROM.

- Edit VM Options, Boot Options, Force BIOS setup

- Save 

 

- Boot the AirWave VM

- In the vm BIOS got right to the Boot option

- Hightlight the CD-ROM option, and ++ to move it above Hard Drive

- Exit, Save Changes, Yes

 

- If Ubuntu use "Try Ubuntu" Option

- open terminal

- sudo fdisk -l to find the boot partition

- sudo mount /dev/sda2 /mnt

- sudo nano /mnt/grub/grub.conf

- delete the line that starts with password

- save file

- umount /mnt

 

While you're here go ahead and re-enable root login.

Find the LVM to mount

- sudo pvs

- sudo lvdisplay /dev/VolGroup00

Mount it:

- sudo mount /dev/VolGroup00/Log/Vol00 /mnt

Change passwd file:

- sudo nano /mnt/etc/passwd

- change the root from nologon to /bin/bash

root:x:0:0:root:/root:/bin/bash

You can also change the ampadmin login over to a terminal rather than going directly into the "imporved" user interface.

Go to the bottom of the file and change /user/local/airwave/bin/ampcli to /bin/bash

- sudo umount /mnt

Shut the system down

-halt

 

Edit the VM setting to disconnect the CDROM and boot into AirWave. 

 

 

 

 

 

I can confirm that the solution to get around the GRUB password works. One thing to take note of if installed on a VM a couple of rescue boot disks could not see my drives. I had to use another Unix disk to get it to be able to find them and depending on type of file type you might have to hunt for the correct one that can mount the drive in read/write and not just write only.

Once I had the right version the instructions worked like a charm.

Before make a major change like this you guys need to deploy and improve a replacement CLI like CPPM CLI - Better than nothing!

Well guys.. HPE killed our beloved Aruba Networks

---

---

Like many Aruba products these days, it´s also plagued by bugs. Even the reset admin password does not work. And updating Airwave? How the hell ? Nothing works. The Upload file does not work. Downloading from Aruba takes forever (literally 15% in 1H). 

Agree! 

Key thing! you guys missed a way to execute the command root;make

Well, the TAC support isn´t the most... fast so it would be interesting to see them look into the speed.

 

Create 2 versions of Airwave. One restricted (could be a FIPS version). One normal, for people who accually want stuff to work.

 

 Also, to say that TAC should build modules? Do you belive in that yourself? That will never happen. So I really do not belive you there.

 

This is a BAD decision. And how you are unable to open up root access on one version is beyond ridiculous. ./unlock root. How hard is it?

Leaving it in for one version or adding a switch is as if not securing it at all. It doesn't fly to have two versions (one locked and one open) and then try to attain high security certifications (FIPS, UCAPL, CC, XXAPL, etc). 

 

If you are having issues with TAC, you can certainly escalate. 

 

I get you're frustrated, but it is what it is at this point. We have avenues in place to support you, but again it's your call whether you want to engage or not. If there are any further questions, I'm happy to answer what I can to help, but otherwise if it's just to state you're unhappy (which I get), there's not much more I can do. Thanks

Thanks for not giving a crap.

 

I will no longer recommend Airwave to any of our customers.

Since we are unable to support it and noting works after the 8.2.4 crap.

 

 

So, I opened up quite a few TAC cases yesterday.

They mentioned that 90% of all new cases was related to this crap.

 

They were unable to find a solution to the upgrade and web password reset problem.

The SSH server they recommended for uploading files did not work.

They later mention that it might only work on mac or Linux. Siad & done. SSH server install on Linux aaaaaand same problem.

 

I cannot upgrade the Airwave and I am still locked out due to the password screwup from Aruba.

 

Still a good product? Nope

If you want to IM me (or post here either way) all your TAC cases, I can escalate them internally for you (unless you're completely done with Aruba and then I won't waste your time). Linux generally doesn't need an SSH server to be installed, with Mac you just need to enable it (it's disabled by default). BitVise is what I use for Windows. 

Tried with several.

Aruba TAC also provided me with a server. Worked great with any client (Filezilla, Flashfxp) but guess what it did not work with? Airwave. 8.2.4 is still haunting me and I am really not happy trying to get out of it.

 

Also, for the love of god. Please update the HPE support portal with the new releases so you accually can download software from there. Having the option when only 8.2.3 is availible is meaningless. How is testing and quality done at Aruba these days? Can you give me a heads up on that?

So... I'm trying to fix wrong timezone and it only can be fixed via CLI, which I don't have since I'm running 8.2.4.

Next thought was that maybe, just maybe there is a newer version of Airwave that has fixed this already and alas, there is. Spanking new 8.2.4.1! So, as a happy chap I am, started upgrade via ampcli (since it is the only option I have) and then there is 'Run fix_missing_indices' error and upgrade is aborted. How the hell I'm supposed to run anything since there is no CLI, just ampcli, which don't listen, just talks?

Any ideas on this? Anyone?

Hi ,

 

We need to run fix_missing_indices scirp to fix this issue for that we need root CLI access. Please open TAC ticket.

 

Regards,

Pavan

Have to call TAC for all issues now.

 

 

Aruba, 

A suggestion:

When you release a new version ensure you have the manual fully built upgrade path from 8.2.4 to 8.2.4.1 is not documented. This shows the lack of support you give to customers and the reason why customers want full access to system. We don't have the time to call TAC for all the minor issues.

apkeene, I will reach out to techpubs to get that added to the next release notes as well as file a request to get more detail about AMP CLI processes in the 8.2.4+ user guide (there's note of the AMP CLI in the UG, but no details on upgrades, etc). Thanks 

Version 8.2.4 just got tagged in a vulnerability scan for HTTP TRACK/TRACE method.  Normally I would edit the .conf file to return 444 NO RESPONSE, but as files are currently inaccessible is this something that can be addressed in the next version?  Perhaps as advanced web server settings menu item.  Also, port 60001 being flagged for multiple issues (incorrect certificate name, weak cert, TRACK/TRACE)

 

 

You would open a TAC case along with the details of the finding (scanner used, output of the finding with details, etc) so that they can loop in our Security folks to determine if it's valid and then patch in a correction.

I have one mory story, too.

Tried to configure Mail in 8.2.4  Thank God, i still have the CLI. :-)

Mails didn't arrive our exchange server.  So i wrote the Mail Relay in the main.cf, restarted postfix and it works.

i figured out, that configuring mail is just working if postfix is stopped. So i stopped and deactivated the service, now everything is fine.

Impossible, to repair this without CLI.

And still there the question, why is postfix running, when it is a problem for Airwave?

 

after changing the ssh key on the server uploads to airwave will fail. because of no cli it is not possible to fix this.

 

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
b9:62:xxxx:ba:4b:5c.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:1
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Permission denied (publickey,gssapi-with-mic,password).
Couldn't connect to <ip>: unable to establish master SSH connection: bad password or master process exited unexpectedly
Hit enter to continue, 's' to show output, 'r' to show return code.

 

Has there been any update on how to clear ssh known_hosts to resolve this? Anyone?

Not yet.  It's a feature request pending review still.

I set up a cron job which sends the controller backups from Airwave to FTP server. Since we updated to Airwave 8.2.5 there is no CLI but it seems the cron job is still running and sending empty backup files to FTP server.

How can I stop that?

I have to delte the cron job but I habe no access.

 

You can call support and they can use a one time password to gain root access. Otherwise, the solution in this thread outlines a way to regain root access. 

Do numbers like 'US16625' reference feature requests for AirWave? Is there a way to see status and likelihood of something being implemented? We would like to configure NIC bonding but it seems the only method is to request TAC assistance.

Your local Aruba account team would be able to reach out internally to find out a status of a feature request and if it's got a roadmap for implementation.

---

@Jafa1995 wrote:

We would like to configure NIC bonding but it seems the only method is to request TAC assistance.

---

In 8.2.6.1, NIC bonding can be configured from the AMPCLI -> Enter Commands:

 

$ help ether
ethernet_bonding <ip> <netmask> <gateway>
Enable ethernet bonding of two network interfaces.
If just 'ethernet_bonding' you will be prompted for the 3 IP addresses.

 

You can only bond 1 pair.

 

Is there any update to this on 8.2.6? I have over 20k alerts that came in before I was able to delete the default alert rule. I used to be able to clean these up with alert_cleanup.pl but am now stuck in the sandbox.

@gosse

 

Open a support case, support will get into the support acct and run the script.

Maybe forbidden, certainly not supported, but I really need to run ping and traceroute.  The bootloader is locked with a password, so I booted the airwave VM from CentOS-6 install meda, entered rescue mode, and let it mount the Airwave filesystem.  I edited /etc/passwd and /etc/shadow, basically copied root's lines but changed the username to admin and the shell to a real shell, but no other fields (uid still 0).  Booted back to Airwave, log in as "admin" with the same password as root had before, and you have a shell.  I'm not sure if this will survive an upgrade (vs. just changing root's shell), but for now it got me what I needed.

 

This wouldn't be needed if they'd provide even a non-root shell account with access to basic tools.

@msturtz

 

ping and traceroute are allowed -> but from the 'Enter Commands' menu.  Those tools are outlined a bit more in this airhead tip.

+1

Just curious if the Clarity VM is going to get the no root access treatment as well?

The "no root CLI" paradigm is fine if everything works the first time.

I was in study and lab mode. I set up VMWare Workstation Player 12 for the first time, and imported the 8.2.4.1 OVA version of AirWave. As typical for a first time exercise, there was a glitch. No web interface, and no way to troubleshoot.

 

I dropped back to 8.2.3.1 and repeated. Same problem, except now I could troubleshoot. From the CLI, I repeated the installation using ./install/amp-install. I pressed ctrl-F9 to see detail of the install process. I then pressed ctrl-F1 to return to the main view. It told me that I needed a static IP. More research showed me that I needed to do that under VMWare, not by using Windows Control Panel to set up a static IP at the physical network interface.

 

If you don't provide root access to the user for the new AirWave builds, you should support a larger list of commands. It would be great to see what services are running, network status, memory and processor usage, etc. It would also be great to be able to launch the installer, as I did.

And here I am opening a TAC case because I can no longer self diagnose basic ssh connectivity issues between Airwave and Aruba controllers.

 

I'm getting tired of talking to TAC. Everytime I have to spend hours engaging TAC something dies inside of me. And I @#$@#ing refuse to go through the long laundry list of information, screenshots, and tarballs they ALWAYS ask for and never look at. 

 

My new policy is I don't answer questions without it being a scheduled remote access session and tying up a tech's time for the entire process. HPE can eat the labor cost of their terrible product design decisions.

 

I didn't see this mentioned so I'll share my issue with the lack of a CLI.  We run AirWave on a Hyper-V server.  When the Hyper-V server was upgraded the virtual switch was deleted.  Now AirWave cannot find eth0.  So I have no network connectivity and no way to fix it.  Sadly, the Aruba support tech didn't seem to understand that SSH and the Support Connection require a working network interface.

@gweyer Had the exact same issue in vmware. TAC ended up mounting an ISO of airwave and booting into rescue mode to extract what the MAC address of what the virtual adapter use to be. I modified the VM Nic to match the previous MAC adddress and this fixed it.

Thank you for the information.  I’ll see if I can get that to work.

Hi I have just upgraded yesterday in version 8.2.5 and I miss already the CLI.  Is there a way to add static routes now ?  

We can add route but need to take TAC help to login as root user to get full shell access.

 

Regards,

Pavan

Is the only option for automated backups in AirWave 8.2.4.1 SCP?  Will FTP become an option in 8.2.5.1?  Also, what are the ramifications of re-enabling root access on the AirWave server?  Is it still supported or will TAC just say sorry, you modifed the install and it's not supported?

I just wanted to add having the exact same problem with Hyper-V and no eth0 so no network.

Aruba have a lovely help page on fixing the issue, but I am unable to run the fix commands in the new reduced CLI.

https://community.arubanetworks.com/t5/Monitoring-Management-Location/Getting-eth-no-more-available-message-on-Airwave/tac-p/433479#M1078

 

So now I need to waste my time and HPE support time to try to fix it.

I need the ability to enable and disable my amps as before so I am not relaint on the Aruba TAC to upgrade my servers to the latest AMP software.

The ability to see my ifconfig if possible to make sure I am on the correct server or sftp to the server the latest image.

 

I am wasting time I could have my servers updated as it stands I was only able to update my backup, not my primary.

 

To take things like this away only makes more work not less.

 

PLEASE GIVE BACK THE CLI!

 

Thanks!

 

Dan

In 8.2.5.1, we introduced the enter cmds option.  The enter cmds allows captive CLI access of allowed cmds.  Check out the release notes to see which cmds were added.  There's going to be another round of cmds being added into this same shell in 8.2.6.

 

You can see your network interface setup under advanced -> network config.  There is a feature to expand this for multiple interfaces in 8.2.6.

 

In regards to file transfer, we're looking to make changes to file transfer in 8.2.6 (Investigating FTP, SFTP, HTTPS)

 

In regards to supportability when you maintain root shell access, we will always attempt to try to help recover from a bad state, but we can't guarantee that you haven't done something else that can't be recovered (like changed time to far in the future, where the only recovery is restoring a backup from before the time change).

Since file transfer does not work. I really hope you are looking into changes for furture releases.

 

Really troublesome QA