So I've gone to 184.108.40.206 now that Heartbleed has been addressed. Why has root been taken away? I know how to get it back but taking away root is like selling me a car then not letting me drive it. As a former UNIX admin, I only run NBU on UNIX platforms and I am ALWAYS super-user.
They obviously didn't spend enough time looking over user shoulders of users who do have Appliances.
Page 35 is the override. And yes, this will be one of the first things I do once I upgrade to 220.127.116.11. When I am on my Appliances 99% of the time I'm executing commands that need to be done as root.
Access to the root account through SSH and the maintenance account has been blocked in 18.104.22.168. because this change improves the overall security of the appliance. SCSP was also included for further security. Just out of curiosity, why else would you need root access to the appliance? The CLISH will configure everything you need and non-root SSH to the appliance should give you everything else.
Just as a side note, only Symantec Support engineers or partners are authorized to override the security policy to gain access to the root account. They may need to do so for several reasons; for example, to resolve a support case. Any unauthorized overrides or disabling of the security policy puts the system in serious risk and voids the warranty and Symantec Support. (As mentioned in HOWTO95668)
The menu system is only good for reboots and downloading patches (unless you have a bandwidth challenged site then you have to push it out there a chunk at a time and then combine it from the command line).
You can't run a --processqueue or a --compactstart or a --dsstat or a --dsstat 1 from the menus.
You can't tail the replication.log, storaged.log, or spoold.log from the menus.
You can't throttle the dedup bandwidth in a meaniful manner from the menus (you have to edit the agent.cnf file).
And, unless they've fixed it, the menu system doesn't even open a share to the right directory to be able to access the results of a DataCollect. You have to go to Elevate to fish it out of tmp (or ftp it someplace).
And if overiding the root lockout voids the warrentee then I think I need to have a serious talk with my managers about NOT upgrading to 2.6.
It's bad enough that Symantec decided to eliminate all 32 bit monitoring and command tools from NBU Enterprise (when a lot of people have 32 bit workstations due to corporate decisions) but to also kill this is one more problem with the 7.6/2.6 so called "upgrade".
I have to say i am with D.Flood on this one - I understand the lock down in a way but most of my advice on this forum for getting appliances working at their best involves dropping into the O/S to edit files or deal with queue processing.
Now it may be that the appliances are now totally perfect at 22.214.171.124 but unless AIR Replication bandwidth throttling and querying the queue processing etc. can be done from the CLISH then there is a problem.
And the line "Any unauthorized overrides or disabling of the security policy puts the system in a serious risk and voids the warranty and Symantec Support." pretty much says that if you do pop into the O/S your warranty and support have gone.
So lets hope they are now as good as they should be and we never need to go into the O/S.
I do notice the first part of the warning which says:
Warning: Only Symantec Support engineers or partners are authorized to override the security policy
so as a Partner i assume we are OK to access it - but users / owners would need assistance from a Partner or Support to avoid invalidating their warranty
I'm pretty sure that this lock-down wasn't run past their Legal Department. Because it constitutes an unannounced, unilateral change to all existing Appliance Support Contracts.
There's nothing on in the download article that mentions that installing 126.96.36.199 will modify the terms of your Support Contract. That's a big red flag.
Ok here is an update. There has been some miscommunication in 188.8.131.52 release notes and documentation (appliance security guide). It states that Symantec support contract and warranty will get voided if one overrides/disables the Symantec Security Policy. This is incorrect. Symantec is working actively to fix the above messaging and will provide updated guides and documentation soon for 184.108.40.206 release. Apologies for the inconvenience and confusion this has caused.
Please note that while you are able to override the Symantec Intrusion Security Policy to gain access to the root account, doing this is still not recommended as it puts the system under risk and makes the system vulnerable to attack.
With recent NetBackup updates, NetBackupCLI functionality has improved, so most of what you're looking to do with root can now be done as NetBackupCLI user.
The data collect issue will be resolved in 220.127.116.11, so I understand wanting to use root for that. As an alternative you can use the appliance GUI to collect the logs.
As a NetBackupCLI user you can do the crcontrol commands you mentioned without having to specify the full path, so it’s even easier. As root you have to give the full path of the crcontrol executable.
You can tail the logs from the CLISH, Support > Logs > Browse > (cd to whichever log directory you like) > tail -f (logname)
Also you can use pdcfg, as a NetBackupCLI user, to throttle the dedup bandwidth:
pdcfg --write=/usr/openv/pdde/pdcr/etc/agent.cfg --section=replication --option=bandwidthlimit --value=1
pdcfg --read=/usr/openv/pdde/pdcr/etc/agent.cfg --section=replication --option=bandwidthlimit
I've noticed that even after disabling the "new" security feature in 18.104.22.168 that winscp will no longer connnect. I rarely ever go into the root console but as mentioned in an earlier post that because the log shares point to the wrong place and because 99% of the time I cant get into them anyways winscp is the only way i have to extract the logs.
Does anyone know a way to get it working?
I had a password assigned to the root account that i used but even after setting that back my connections are still getting accessed denied.
Tell you guys I'm not good with this. I can't tell you how much time I spend in the shell running commands, checking configs, etc. Its faster. Please don't tell me about directory typing shortcuts as a plus when I'd lose so much. This change is seriously going to make me/us look at the appliances very differently when it comes to designing out our backup solution.
I am sorry you are having issues with the security enhancements. Please give me a little more info on what you wanted to do and I can take them to our engineering team to request enhancements to the appliance interface.
I'm just having trouble getting the winscp software to connect. This may or may not be linked to the security features but it is related to a change because I have 2 appliances and one is at 22.214.171.124 and the other at 126.96.36.199. The "2" versioned appliance will no longer connect via winscp. This is mainly something to do with the changing of root access i would think.
A few version back this was broken as well and a support rep tipped me off to assigning the root account a password and then i was able to connect no problem. But it appears after assigning a root password i can no longer connect.
The winscp program has proved to be VERY useful for me being mainly a windows guy. Thank you for offering up some assistance on this.
I am currently installing two appliances and have seen them in 188.8.131.52 and 184.108.40.206 versions (new appliances re-imaged to 220.127.116.11 using ISO image and then when 18.104.22.168 came out they were re-imaged again before configuration.
Now one of them has an issue with the IPMI interface dropping out all of the time - totally going off line and not even ping-able.
So the ipmitool bmc reset cold helps - but only for a little while (on .0.1 and .0.2) before it drops again
So the big fix for 5230 appliances is to use the intel_tools option as outlined here:
Maybe that should also be available from the CLISH .. but it does not even exist on 22.214.171.124 or 126.96.36.199.
I have a case open with support (06722970) and will update when i get contacted .. being efficient i did a DataCollect ready for them .. but i cannot get that off the appliance either - everything is access denied when i map a drive to it - some complete folders and all files that i can see, including the DataCollect.zip.
So there really does seem issues here - been installing appliances since the 5200 running 1.1 and never had such a difficult experience!
To be honest I like these changes. For sure it makes my life more troublesome because I have to override the security everytime I have to fix a problem on a customers appliance....BUT we had customers in the past that ran commands as root and messed things up. They then stated that they did't do anything (we saw commands in the history...). Now at least we have Symantec officialy stating that you void the warranty if you touch this without being a Symantec engineer or partner.
Sorry for post on older thread but I just had to backup Symantec on this one.
I was skeptical at first, but once I've used NetBackupCLI user, it looks like it does about 99% of what you usually want to do "as root". Complaining about this is surely expected, but I find it's like complaining about having to use "sudo" instead of logging in directly as "root" (no, it's not the exact same thing, but it's one of those steps that's annoying at first, but you become accustom to it, and for all the right reasons). Overall you can do what you want, but it's more secure and better designed with very little overhead (once you have NetBackupCLI users, which is trivial to use)
These "security" changes have ensured that this will be the last appliance that our organisation ever purchases. It is already bad enough that the appliance lags behind on security updates compared to the others OS's we run (around 300 Redhat servers, 30 Solaris servers, and enough Windiows servers as required for MS-Exchange and basic file server operations). We have a team of 8 admins with an aggregate experience of 140 years. Yet WE are going to place our system at risk!?! I think not.
We have had to rewrite many of the custom monitoring sripts to work around this newly introduced problem, and our tape operators have had to change their procedures to manage the robotic tape library. As others have stated: many of the netbackup commands are ONLY available from the command line. Or at best awkwardly from the menu system.
Now, where did I leave thoise TSM install disks?......
I don't see how these changes can have any effect on tape librarys ?
An appliance is a closed system so you shouldn't even be running your "own" monitoring scripts on it. If you want an environment with more control you can choose to setup your own Netbackup system which you control.
It's exactly because of people like this (not referring to you), who tamper with the appliance without being certified to do so, who trigger reactions like this from Symantec.
I see many customers who break their netbackup installation because they wanted to change something, right now they can only change what is possible and not things that they should not be changing in the first place.
I am with you on the security updates, but serious issues are handled immediately by symantec so that's fine. And again, you have the option to setup your own netbackup system where you handle the updates. If you choose an appliance then it's closed so that's it...seem you made the wrong choice.